This is a port of @eddyb's `const-fn` branch. I rebased it, tweaked a few things, and added tests as well as a feature gate. The set of tests is still pretty rudimentary, I'd appreciate suggestions on new tests to write. Also, a double-check that the feature-gate covers all necessary cases.
One question: currently, the feature-gate allows the *use* of const functions from stable code, just not the definition. This seems to fit our usual strategy, and implies that we might (perhaps) allow some constant functions in libstd someday, even before stabilizing const-fn, if we were willing to commit to the existence of const fns but found some details of their impl unsatisfactory.
r? @pnkfelix
- add feature gate
- add basic tests
- adjust parser to eliminate conflict between `const fn` and associated
constants
- allow `const fn` in traits/trait-impls, but forbid later in type check
- correct some merge conflicts
Closes#17841.
The majority of the work should be done, e.g. trait and inherent impls, different forms of UFCS syntax, defaults, and cross-crate usage. It's probably enough to replace the constants in `f32`, `i8`, and so on, or close to good enough.
There is still some significant functionality missing from this commit:
- ~~Associated consts can't be used in match patterns at all. This is simply because I haven't updated the relevant bits in the parser or `resolve`, but it's *probably* not hard to get working.~~
- Since you can't select an impl for trait-associated consts until partway through type-checking, there are some problems with code that assumes that you can check constants earlier. Associated consts that are not in inherent impls cause ICEs if you try to use them in array sizes or match ranges. For similar reasons, `check_static_recursion` doesn't check them properly, so the stack goes ka-blooey if you use an associated constant that's recursively defined. That's a bit trickier to solve; I'm not entirely sure what the best approach is yet.
- Dealing with consts associated with type parameters will raise some new issues (e.g. if you have a `T: Int` type parameter and want to use `<T>::ZERO`). See rust-lang/rfcs#865.
- ~~Unused associated consts don't seem to trigger the `dead_code` lint when they should. Probably easy to fix.~~
Also, this is the first time I've been spelunking in rustc to such a large extent, so I've probably done some silly things in a couple of places.
local only if matches `FUNDAMENTAL(LocalType)`, where `FUNDAMENTAL`
includes `&T` and types marked as fundamental (which includes `Box`).
Also apply these tests to negative reasoning.
This is a deprecated attribute that is slated for removal, and it also affects
all implementors of the trait. This commit removes the attribute and fixes up
implementors accordingly. The primary implementation which was lost was the
ability to compare `&[T]` and `Vec<T>` (in that order).
This change also modifies the `assert_eq!` macro to not consider both directions
of equality, only the one given in the left/right forms to the macro. This
modification is motivated due to the fact that `&[T] == Vec<T>` no longer
compiles, causing hundreds of errors in unit tests in the standard library (and
likely throughout the community as well).
Closes#19470
[breaking-change]
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).
