-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
rustc: Tweak #[target_feature]
syntax
#47223
Conversation
r? @eddyb (rust_highfive has picked a reviewer for you, use r? to override) |
src/librustc/ty/maps/mod.rs
Outdated
@@ -360,6 +360,9 @@ define_maps! { <'tcx> | |||
// however, which uses this query as a kind of cache. | |||
[] fn erase_regions_ty: erase_regions_ty(Ty<'tcx>) -> Ty<'tcx>, | |||
[] fn fully_normalize_monormophic_ty: normalize_ty_node(Ty<'tcx>) -> Ty<'tcx>, | |||
|
|||
[] fn target_features_whitelist: target_features_whitelist_node(CrateNum) -> Rc<Vec<String>>, | |||
[] fn target_features_enabled: TargetFeaturesEnabled(DefId) -> Rc<Vec<String>>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you maybe use BTreeSet<Symbol>
? Or is that too much of a microoptimization? (I was thinking we could speed up checking for a specific target feature that way)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Realistically there will be at most a dozen or so target features, I wouldn't expect a b-tree to beat linear search for such small collections.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we really cared about performance we would use a binary search into a sorted Vec
.
if tcx.fn_sig(id).unsafety() == Unsafety::Normal { | ||
let msg = "#[target_feature(..)] can only be applied to \ | ||
`unsafe` function"; | ||
tcx.sess.span_err(attr.span, msg); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I almost missed this: it's a very bad idea to have these checks here (as opposed to rustc_typeck
) because they'd only trigger on monomorphizations.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you have a suggestion for where this might go? This is the same bug about validating #[inline(never)]
and such I think? (in the sense that this isn't the first of it's kind and it's not clear if there's an obvious way to fix this)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
inline
and some aspects of repr
(whether they are applied to the right kind of item, there are further checks in rustc_typeck) are checked in rustc::hir::check_attr
. It seems these checks would fit in nicely there, since they doen't seem to need any type information.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the pointer! Needed a bit of refactoring but it fits there now.
This PR seems fine to me, other than the small nit that I find it weird that the implementation of |
☔ The latest upstream changes (presumably #47200) made this pull request unmergeable. Please resolve the merge conflicts. |
@nagisa disabling features was explicitly mentioned as a future feature, so it's not implemented here (as it's more conservative to not implement it yet). |
dc2b1e7
to
40a4131
Compare
r? @eddyb |
@bors r+ |
📌 Commit 40a4131 has been approved by |
⌛ Testing commit 40a41316d1fb9d9da9409e7527fd00fedd752d46 with merge 235732a61138adc2c7118c9275a3f2fb1e45deb3... |
💔 Test failed - status-travis |
// except according to those terms. | ||
|
||
// ignore-arm | ||
// ignore-aarch64 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Needs ignore-wasm
here. Actually I think all non-x86 architectures need to be ignored.
[00:47:27] failures:
[00:47:27]
[00:47:27] ---- [ui] ui/target-feature-wrong.rs stdout ----
[00:47:27] diff of stderr:
[00:47:27]
[00:47:27] 28 26 | #[target_feature(enable = "sse2")]
[00:47:27] 29 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[00:47:27] 30
[00:47:27] + error: the feature named `sse2` is not valid for this target
[00:47:27] + --> $DIR/target-feature-wrong.rs:26:18
[00:47:27] + |
[00:47:27] + 26 | #[target_feature(enable = "sse2")]
[00:47:27] + | ^^^^^^^^^^^^^^^
[00:47:27] +
[00:47:27] + error: aborting due to 5 previous errors
[00:47:27] - error: aborting due to 4 previous errors
[00:47:27] 32
[00:47:27] 33
This is an implementation of the `#[target_feature]` syntax-related changes of [RFC 2045][rfc]. Notably two changes have been implemented: * The new syntax is `#[target_feature(enable = "..")]` instead of `#[target_feature = "+.."]`. The `enable` key is necessary instead of the `+` to indicate that a feature is being enabled, and a sub-list is used for possible expansion in the future. Additionally within this syntax the feature names being enabled are now whitelisted against a known set of target feature names that we know about. * The `#[target_feature]` attribute can only be applied to unsafe functions. It was decided in the RFC that invoking an instruction possibly not defined for the current processor is undefined behavior, so to enable this feature for now it requires an `unsafe` intervention. [rfc]: https://github.com/rust-lang/rfcs/blob/master/text/2045-target-feature.md
40a4131
to
03d76e6
Compare
@bors: r=eddyb |
📌 Commit 03d76e6 has been approved by |
⌛ Testing commit 03d76e67ee47f6c0642bf6b9f725d1909106170e with merge d48ae78bcb4de40f94288ee34fef5f3cddd9151c... |
💔 Test failed - status-travis |
This'll enable running queries that could be cached and overall be more amenable to the query infastructure.
03d76e6
to
0ecaa67
Compare
@bors: r=eddyb |
📌 Commit 0ecaa67 has been approved by |
rustc: Tweak `#[target_feature]` syntax This is an implementation of the `#[target_feature]` syntax-related changes of [RFC 2045][rfc]. Notably two changes have been implemented: * The new syntax is `#[target_feature(enable = "..")]` instead of `#[target_feature = "+.."]`. The `enable` key is necessary instead of the `+` to indicate that a feature is being enabled, and a sub-list is used for possible expansion in the future. Additionally within this syntax the feature names being enabled are now whitelisted against a known set of target feature names that we know about. * The `#[target_feature]` attribute can only be applied to unsafe functions. It was decided in the RFC that invoking an instruction possibly not defined for the current processor is undefined behavior, so to enable this feature for now it requires an `unsafe` intervention. [rfc]: https://github.com/rust-lang/rfcs/blob/master/text/2045-target-feature.md
☀️ Test successful - status-appveyor, status-travis |
whitelist x86 fxsr feature rust-lang#47223 properly checks that only white-listed features are allowed in combination with `target_feature`, but the `fxsr` feature used by `stdsimd` was not white-listed. r? @alexcrichton
This is an implementation of the
#[target_feature]
syntax-related changes ofRFC 2045. Notably two changes have been implemented:
The new syntax is
#[target_feature(enable = "..")]
instead of#[target_feature = "+.."]
. Theenable
key is necessary instead of the+
to indicate that a feature is being enabled, and a sub-list is used for
possible expansion in the future. Additionally within this syntax the feature
names being enabled are now whitelisted against a known set of target feature
names that we know about.
The
#[target_feature]
attribute can only be applied to unsafe functions. Itwas decided in the RFC that invoking an instruction possibly not defined for
the current processor is undefined behavior, so to enable this feature for now
it requires an
unsafe
intervention.