Feature gate custom attributes #22364
Conversation
|
cc @nick29581 |
|
This doesn't completely implement the backwards compatibility we need for attributes. There's also the case of attributes like But the requirements for each of the builtin attributes are different so I don't see a way of doing this here. Adding some sort of individual check for each sounds doable though. |
Manishearth
force-pushed
the
rfc-572-forbid-attr
branch
3 times, most recently
from
79b3c9b
to
d5c3194
Compare
- We shouldn't be using `check_name` here at all - `contains_name(ref_slice(foo), bar)` is redundant, `contains_name` just iterates over its first arg and calls `check_name` - match would be better than a bunch of ifs
| unknown to the the compiler and \ | ||
| may have meaning \ | ||
| added to it in the future", | ||
| attr.name()).as_slice()); |
There was a problem hiding this comment.
The interaction between #22336 and this is interesting. I think I'd like a way to include something in the table of custom attributes but still declare that it requires a (perhaps generic) feature-gate. This would be the case for things like rustc_move_fragments and rustc_variance. Or we could add them to the list above, but it seems a bit redundant. (It might also be nice to be able to just write something like FeatureGate("tag") and get a generic message like "The attribute {} has unstable semantics and requires the feature-gate {}".
There was a problem hiding this comment.
Yeah, Gated("tag") (and perhaps even Deprecated("reason")) sound like useful additions to the list.
|
@Manishearth ok r+ with the addition of |
Manishearth
force-pushed
the
rfc-572-forbid-attr
branch
from
1a58d22
to
0112f3b
Compare
|
@bors r=nikomatsakis 0112 aka cute little fibonacci |
|
@bors r- until rustc_variance and friends are feature-gated |
|
@bors r+ 917fce2 |
Manishearth
force-pushed
the
rfc-572-forbid-attr
branch
from
917fce2
to
f64d71b
Compare
…nikomatsakis fixes rust-lang#22203 r? @nikomatsakis This breaks code that might be using attributes randomly, so it's technically a [breaking-change]
fixes #22203
r? @nikomatsakis
This breaks code that might be using attributes randomly, so it's technically a
[breaking-change]