[Syntax] Implement auto trait syntax
Implements `auto trait Send {}` as a substitute for `trait Send {} impl Send for .. {}`.
See the [internals thread](https://internals.rust-lang.org/t/pre-rfc-renaming-oibits-and-changing-their-declaration-syntax/3086) for motivation. Part of #13231.
The first commit is just a rename moving from "default trait" to "auto trait". The rest is parser->AST->HIR work and making it the same as the current syntax for everything below HIR. It's under the `optin_builtin_traits` feature gate.
When can we remove the old syntax? Do we need to wait for a new `stage0`? We also need to formally decide for the new form (even if the keyword is not settled yet).
Observations:
- If you `auto trait Auto {}` and then `impl Auto for .. {}` that's accepted even if it's redundant.
- The new syntax is simpler internally which will allow for a net removal of code, for example well-formedness checks are effectively moved to the parser.
- Rustfmt and clippy are broken, need to fix those.
- Rustdoc just ignores it for now.
ping @petrochenkov @nikomatsakis
DefaultImpl is a highly confusing name for what we now call auto impls,
as in `impl Send for ..`. The name auto impl is not formally decided
but for sanity anything is better than `DefaultImpl` which refers
neither to `default impl` nor to `impl Default`.
At reviewer's suggestion, we remove the function/static name from the
main lint message. While we're correspondingly adjusting the
expectations of a compile-fail test, we remove an obsolete FIXME
comment, another quantum of progress towards resolving the fabulous
metabug #44366.
This comment made sense when it was introduced in fbef2417. It does not
make sense in its current context, where the referred-to guard is no
longer present.
This being an item under the fabulous metabug #44366.
This updates the borrowck query to return a result, and this result is then used
to incrementally check for unused mutable nodes given sets of all the used
mutable nodes.
Closes#42384
Although RFC 1940 is about annotating functions with `#[must_use]`, a
key part of the motivation was linting unused equality operators.
(See
https://github.com/rust-lang/rfcs/pull/1812#issuecomment-265695898—it
seems to have not been clear to discussants at the time that marking the
comparison methods as `must_use` would not give us the lints on
comparison operators, at least in (what the present author understood
as) the most straightforward implementation, as landed in #43728
(3645b062).)
To rectify the situation, we here lint unused comparison operators as
part of the unused-must-use lint (feature gated by the `fn_must_use`
feature flag, which now arguably becomes a slight (tolerable in the
opinion of the present author) misnomer).
This is in the matter of #43302.
Evaluate fixed-length array length expressions lazily.
This is in preparation for polymorphic array lengths (aka `[T; T::A]`) and const generics.
We need deferred const-evaluation to break cycles when array types show up in positions which require knowing the array type to typeck the array length, e.g. the array type is in a `where` clause.
The final step - actually passing bounds in scope to array length expressions from the parent - is not done because it still produces cycles when *normalizing* `ParamEnv`s, and @nikomatsakis' in-progress lazy normalization work is needed to deal with that uniformly.
However, the changes here are still useful to unlock work on const generics, which @EpicatSupercell manifested interest in, and I might be mentoring them for that, but we need this baseline first.
r? @nikomatsakis cc @oli-obk
This'll allow us to reconstruct query parameters purely from the `DepNode`
they're associated with. Some queries could move straight to `HirId` but others
that don't always have a correspondance between `HirId` and `DefId` moved to
two-level maps where the query operates over a `DefIndex`, returning a map,
which is then keyed off `ItemLocalId`.
Closes#44414
Migrate a slew of metadata methods to queries
This PR intends to make more progress on #41417, knocking off some low-hanging fruit.
Closes#44190
cc #44137
This commit moves the calculation of the `LanguageItems` structure into a
query rather than being calculated before the `TyCtxt` exists, with the eventual
end goal of removing some `CrateStore` methods.
The main use of `CrateStore` *before* the `TyCtxt` is created is during
resolution, but we want to be sure that any methods used before resolution are
not used after the `TyCtxt` is created. This commit starts moving the methods
used by resolve to all be named `{name}_untracked` where the rest of the
compiler uses just `{name}` as a query.
During this transition a number of new queries were added to account for
post-resolve usage of these methods.
rustc: Flag {i,u}128 as unsafe for FFI
These don't appear to have a stable ABI as noted in #41799 and the work in
compiler-builtins definitely seems to be confirming it!
rustc: Remove the `used_unsafe` field on TyCtxt
Now that lint levels are available for the entire compilation, this can be an
entirely local lint in `effect.rs`
cc #44137
We'll actually want a new "soft" warning-only gate to maintain
backwards-compatibility, but it's cleaner to start out with the established,
well-understood gate before implementing the alternative warn-only behavior in
a later commit.
This is in the matter of #43302.