warn when using an unstable feature with -Ctarget-feature #117616
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
(rustbot has picked a reviewer for you, use r? to override) |
rustbot
added
S-waiting-on-review
This comment has been minimized.
This comment has been minimized.
RalfJung
force-pushed
the
unstable-target-features
branch
from
6c0dc97
to
c23b9ee
Compare
RalfJung
force-pushed
the
unstable-target-features
branch
from
c23b9ee
to
b85c683
Compare
| @@ -76,8 +76,8 @@ codegen_llvm_target_machine = could not create LLVM TargetMachine for triple: {$ | |||
| codegen_llvm_target_machine_with_llvm_err = could not create LLVM TargetMachine for triple: {$triple}: {$llvm_err} | |||
|
|
|||
| codegen_llvm_unknown_ctarget_feature = | |||
| unknown feature specified for `-Ctarget-feature`: `{$feature}` | |||
| .note = it is still passed through to the codegen backend | |||
| unknown and unstable feature specified for `-Ctarget-feature`: `{$feature}` | |||
There was a problem hiding this comment.
Why? I don't totally understand how something can both be unknown and unstable.
There was a problem hiding this comment.
If it's unknown it's clearly not stable, and hence it is unstable.
There was a problem hiding this comment.
Why does that need clarification? Like, if it's clearly not stable by virtue of being uknown, why are we saying it's unknown and unstable?
There was a problem hiding this comment.
I think it's worth emphasizing that unknown implies unstable. Unstable has a particular meaning in the Rust context, and that implication is very clear to us, but might not be clear at all to users.
It is extremely unusual that we allow unstable things to even be done on stable Rust, making it even more important to point this out explicitly.
|
@bors r+ idk if you intended this to go through an FCP, but it's a warning, and I think the warning is well-justified, so I see no reason for that. you can r- if you disagree, and I can start one. |
bors
added
S-waiting-on-bors
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Nov 7, 2023
…=compiler-errors warn when using an unstable feature with -Ctarget-feature Setting or unsetting the wrong target features can cause ABI incompatibility (rust-lang#116344, rust-lang#116558). We need to carefully audit features for their ABI impact before stabilization. I just learned that we currently accept arbitrary unstable features on stable and if they are in the list of Rust target features, even unstable, then we don't even warn about that!1 That doesn't seem great, so I propose we introduce a warning here. This has an obvious loophole via `-Ctarget-cpu`. I'm not sure how to best deal with that, but it seems better to fix what we can and think about the other cases later, maybe once we have a better idea for how to resolve the general mess that are ABI-affecting target features.
This comment has been minimized.
This comment has been minimized.
|
💔 Test failed - checks-actions |
bors
added
S-waiting-on-review
|
@bors r=compiler-errors |
bors
added
S-waiting-on-bors
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Nov 7, 2023
…iaskrgr Rollup of 4 pull requests Successful merges: - rust-lang#115485 (Format macro const literals with pretty printer) - rust-lang#117616 (warn when using an unstable feature with -Ctarget-feature) - rust-lang#117639 (Update books) - rust-lang#117675 (llvm-wrapper: Remove include of non-existant Vectorize.h) r? `@ghost` `@rustbot` modify labels: rollup
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Nov 7, 2023
Rollup merge of rust-lang#117616 - RalfJung:unstable-target-features, r=compiler-errors warn when using an unstable feature with -Ctarget-feature Setting or unsetting the wrong target features can cause ABI incompatibility (rust-lang#116344, rust-lang#116558). We need to carefully audit features for their ABI impact before stabilization. I just learned that we currently accept arbitrary unstable features on stable and if they are in the list of Rust target features, even unstable, then we don't even warn about that!1 That doesn't seem great, so I propose we introduce a warning here. This has an obvious loophole via `-Ctarget-cpu`. I'm not sure how to best deal with that, but it seems better to fix what we can and think about the other cases later, maybe once we have a better idea for how to resolve the general mess that are ABI-affecting target features.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Setting or unsetting the wrong target features can cause ABI incompatibility (#116344, #116558). We need to carefully audit features for their ABI impact before stabilization. I just learned that we currently accept arbitrary unstable features on stable and if they are in the list of Rust target features, even unstable, then we don't even warn about that!1 That doesn't seem great, so I propose we introduce a warning here.
This has an obvious loophole via
-Ctarget-cpu. I'm not sure how to best deal with that, but it seems better to fix what we can and think about the other cases later, maybe once we have a better idea for how to resolve the general mess that are ABI-affecting target features.