Earlier commits impose rules on lifetimes that make generic
destructors safe; thus we no longer need the `#[unsafe_destructor]`
attribute nor its associated check.
----
So remove the check for the unsafe_destructor attribute.
And remove outdated compile-fail tests from when lifetime-parameteric
dtors were disallowed/unsafe.
In addition, when one uses the attribute without the associated
feature, report that the attribute is deprecated.
However, I do not think this is a breaking-change, because the
attribute and feature are still currently accepted by the compiler.
(After the next snapshot that has this commit, we can remove the
feature itself and the attribute as well.)
----
I consider this to:
Fix#22196
(techincally there is still the post snapshot work of removing the
last remants of the feature and the attribute, but the ticket can
still be closed in my opinion).
This attribute has been deprecated in favor of #[should_panic]. This also
updates rustdoc to no longer accept the `should_fail` directive and instead
renames it to `should_panic`.
This attribute has been deprecated in favor of #[should_panic]. This also
updates rustdoc to no longer accept the `should_fail` directive and instead
renames it to `should_panic`.
This commit removes compiler support for the `old_impl_check` attribute which
should in theory be entirely removed now. The last remaining use of it in the
standard library has been updated by moving the type parameter on the
`old_io::Acceptor` trait into an associated type. As a result, this is a
breaking change for all current users of the deprecated `old_io::Acceptor`
trait. Code can be migrated by using the `Connection` associated type instead.
[breaking-change]
* no_split_stack was renamed to no_stack_check
* deriving was renamed to derive
* `use foo::mod` was renamed to `use foo::self`;
* legacy lifetime definitions in closures have been replaced with `for` syntax
* `fn foo() -> &A + B` has been deprecated for some time (needs parens)
* Obsolete `for Sized?` syntax
* Obsolete `Sized? Foo` syntax
* Obsolete `|T| -> U` syntax
When this attribute is applied to a function, its return value gets the
noalias attribute, which is how you tell LLVM that the function returns
a "new" pointer that doesn't alias anything accessible to the caller,
i.e. it acts like a memory allocator.
Plain malloc doesn't need this attribute because LLVM already knows
about malloc and adds the attribute itself.
This is a hack, but I don't think we can do much better as long as `derive` is
running at the syntax expansion phase.
If the custom_derive feature gate is enabled, this works with user-defined
traits and syntax extensions. Without the gate, you can't use e.g. #[derive_Clone]
directly, so this does not change the stable language.
This commit also cleans up the deriving code somewhat, and forbids some
previously-meaningless attribute syntax. For this reason it's technically a
[breaking-change]
Unstable items used in a macro expansion will now always trigger
stability warnings, *unless* the unstable items are directly inside a
macro marked with `#[allow_internal_unstable]`. IOW, the compiler warns
unless the span of the unstable item is a subspan of the definition of a
macro marked with that attribute.
E.g.
#[allow_internal_unstable]
macro_rules! foo {
($e: expr) => {{
$e;
unstable(); // no warning
only_called_by_foo!();
}}
}
macro_rules! only_called_by_foo {
() => { unstable() } // warning
}
foo!(unstable()) // warning
The unstable inside `foo` is fine, due to the attribute. But the
`unstable` inside `only_called_by_foo` is not, since that macro doesn't
have the attribute, and the `unstable` passed into `foo` is also not
fine since it isn't contained in the macro itself (that is, even though
it is only used directly in the macro).
In the process this makes the stability tracking much more precise,
e.g. previously `println!("{}", unstable())` got no warning, but now it
does. As such, this is a bug fix that may cause [breaking-change]s.
The attribute is definitely feature gated, since it explicitly allows
side-stepping the feature gating system.
---
This updates `thread_local!` macro to use the attribute, since it uses
unstable features internally (initialising a struct with unstable
fields).
Unstable items used in a macro expansion will now always trigger
stability warnings, *unless* the unstable items are directly inside a
macro marked with `#[allow_internal_unstable]`. IOW, the compiler warns
unless the span of the unstable item is a subspan of the definition of a
macro marked with that attribute.
E.g.
#[allow_internal_unstable]
macro_rules! foo {
($e: expr) => {{
$e;
unstable(); // no warning
only_called_by_foo!();
}}
}
macro_rules! only_called_by_foo {
() => { unstable() } // warning
}
foo!(unstable()) // warning
The unstable inside `foo` is fine, due to the attribute. But the
`unstable` inside `only_called_by_foo` is not, since that macro doesn't
have the attribute, and the `unstable` passed into `foo` is also not
fine since it isn't contained in the macro itself (that is, even though
it is only used directly in the macro).
In the process this makes the stability tracking much more precise,
e.g. previously `println!("{}", unstable())` got no warning, but now it
does. As such, this is a bug fix that may cause [breaking-change]s.
The attribute is definitely feature gated, since it explicitly allows
side-stepping the feature gating system.
This changes the type of some public constants/statics in libunicode.
Notably some `&'static &'static [(char, char)]` have changed
to `&'static [(char, char)]`. The regexp crate seems to be the
sole user of these, yet this is technically a [breaking-change]
The API this exposes is a little strange (being attached to `static`s),
so it makes sense to conservatively feature gate it. If it is highly
popular, it is possible to reverse this gating.
The API this exposes is a little strange (being attached to `static`s),
so it makes sense to conservatively feature gate it. If it is highly
popular, it is possible to reverse this gating.
This changes the type of some public constants/statics in libunicode.
Notably some `&'static &'static [(char, char)]` have changed
to `&'static [(char, char)]`. The regexp crate seems to be the
sole user of these, yet this is technically a [breaking-change]
they are used without a feature-gate. This is both kinder to existing
code and should make it easier to land this PR, since we don't
have to catch EVERY SINGLE SUFFIX.
Pass features along during expansion
Use the set of passed features to detect uses of feature-gated macros without the corresponding feature enabled.
Fix#22234.
----
Also, the framework this add (passing along a reference to the features in the expansion context) is a necessary precursor for landing a properly feature-gated desugaring-based overloaded-`box` and placement-`in` (#22181).
----
This is fixing a bug, but since there might be code out there that is unknowingly taking advantage of that bug, I feel obligated to mark this as a:
[breaking-change]
- 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
Added all active features to the list in reference.md.
Added a second note about keeping the reference.md list up-to-date to the bottom of the list, since not everyone (including me) reads the big comment at the top of it. :)
Ensured that the feature gate list in reference.md is kept in alphabetical order.
