Skip to content

require a consistent codegen backend when -Zllvm-target-feature is present - #160618

Open
RalfJung wants to merge 2 commits into
rust-lang:mainfrom
RalfJung:llvm-target-feature-codegen-backends
Open

require a consistent codegen backend when -Zllvm-target-feature is present#160618
RalfJung wants to merge 2 commits into
rust-lang:mainfrom
RalfJung:llvm-target-feature-codegen-backends

Conversation

@RalfJung

@RalfJung RalfJung commented Aug 6, 2026

Copy link
Copy Markdown
Member

Finishes the implementation of #157753 by ensuring that we don't mix codegen backends when using backend-specific target features (as other backends would ignore those).

The 2nd commit customizes the error we get to be a bit more helpful. I don't know how to do that with the diagnostic structs, so I converted this to use the builder API, which also deduplicated some strings.

r? @folkertdev
Cc @davidtwco @azhogin I hope I am using target modifiers correctly :D

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Aug 6, 2026
@rust-log-analyzer

This comment has been minimized.

@RalfJung
RalfJung force-pushed the llvm-target-feature-codegen-backends branch from 34238f6 to 6bf460d Compare August 6, 2026 08:53
checksum_hash_algorithm: Option<SourceFileHashAlgorithm> = (None, parse_cargo_src_file_hash, [TRACKED],
"hash algorithm of source files used to check freshness in cargo (`blake3` or `sha256`)"),
codegen_backend: Option<String> = (None, parse_opt_string, [TRACKED],
codegen_backend: Option<String> = (None, parse_opt_string, [TRACKED] { TARGET_MODIFIER: CodegenBackend },

@bjorn3 bjorn3 Aug 6, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This would encode the codegen backend path in the crate metadata if a path is passed to -Zcodegen-backend, right? That would both hurt reproducibility and give false positives if the codegen backend is at a different location on a different machine.

The CodegenBackend trait has a name method that can be used instead.

View changes since the review

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah looks like that is what happens.

Unfortunately I don't know how to record that name rather than the actual value of the flag...

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Was this resolved or?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No. Maybe @davidtwco @azhogin have advice for how to best retain a "normalized" value for a target modifier, rather than the actual flag value.

In #160593 I am adding the concept of a "synthetic" target modifier that we could also use, but it's kind of hacky the way I did it so I'll hold off on feedback on that PR before adding more such things.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In that case

@rustbot author

@RalfJung RalfJung Aug 19, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The actually loaded codegen backend is not stored in Session, right? So recording its name() might be even more annoying than what I had to do in #160593. :/

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure if there's a way to avoid this with the current infrastructure. In #160167, I change to encoding the type of the field itself rather than the string that the user provides (which is subsequently re-parsed), which could make it easier to serialise a reduced form of it (just whether it is LLVM/GCC/Cranelift w/out the specific path) but that would require a little bit of tweaking on what I have.

@rust-log-analyzer

This comment has been minimized.

@RalfJung
RalfJung force-pushed the llvm-target-feature-codegen-backends branch from 6bf460d to ce5650d Compare August 6, 2026 10:20
@rustbot rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 7, 2026
@rust-bors

This comment has been minimized.

@RalfJung
RalfJung force-pushed the llvm-target-feature-codegen-backends branch from ce5650d to 89fe5bb Compare August 17, 2026 09:28
@rustbot

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@RalfJung
RalfJung force-pushed the llvm-target-feature-codegen-backends branch from ab764ef to 6c38dd1 Compare August 19, 2026 15:26
@rustbot

rustbot commented Aug 19, 2026

Copy link
Copy Markdown
Collaborator

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants