Remove unused feature gates
I think many of the remaining unstable things can be easily be replaced with stable things. I have kept the `#![feature(nll)]` even though it is only necessary in `libstd`, to make regressions of it harder.
replace the leak check with universes, take 2
This PR is an attempt to revive the "universe-based region check", which is an important step towards lazy normalization. Unlike before, we also modify the definition of `'empty` so that it is indexed by a universe. This sidesteps some of the surprising effects we saw before -- at the core, we no longer think that `exists<'a> { forall<'b> { 'b: 'a } }` is solveable. The new region lattice looks like this:
```
static ----------+-----...------+ (greatest)
| | |
early-bound and | |
free regions | |
| | |
scope regions | |
| | |
empty(root) placeholder(U1) |
| / |
| / placeholder(Un)
empty(U1) -- /
| /
... /
| /
empty(Un) -------- (smallest)
```
This PR has three effects:
* It changes a fair number of error messages, I think for the better.
* It fixes a number of bugs. The old algorithm was too conservative and caused us to reject legal subtypings.
* It also causes two regressions (things that used to compile, but now do not).
* `coherence-subtyping.rs` gets an additional error. This is expected.
* `issue-57639.rs` regresses as before, for the reasons covered in #57639.
Both of the regressions stem from the same underlying property: without the leak check, the instantaneous "subtype" check is not able to tell whether higher-ranked subtyping will succeed or not. In both cases, we might be able to fix the problem by doing a 'leak-check like change' at some later point (e.g., as part of coherence).
This is a draft PR because:
* I didn't finish ripping out the leak-check completely.
* We might want to consider a crater run before landing this.
* We might want some kind of design meeting to cover the overall strategy.
* I just remembered I never finished 100% integrating this into the canonicalization code.
* I should also review what happens in NLL region checking -- it probably still has a notion of bottom (empty set).
r? @matthewjasper
We now make `'empty` indexed by a universe index, resulting
in a region lattice like this:
```
static ----------+-----...------+ (greatest)
| | |
early-bound and | |
free regions | |
| | |
scope regions | |
| | |
empty(root) placeholder(U1) |
| / |
| / placeholder(Un)
empty(U1) -- /
| /
... /
| /
empty(Un) -------- (smallest)
```
Therefore, `exists<A> { forall<B> { B: A } }` is now unprovable,
because A must be at least Empty(U1) and B is placeholder(U2), and hence
the two regions are unrelated.
rustdoc: attempt full build for compile_fail test
Some code fails when doing a full build but does not fail when only emitting metadata. This commit makes sure compile_fail tests for such code behave as expected, that is, the test succeeds because the compilation fails.
Fixes#67771.
fix couple of perf related clippy warnings
librustc: don't clone a type that is copy
librustc_incremental: use faster vector initialization
librustc_typeck: don't clone a type that is copy
librustdoc: don't create a vector where a slice will do
librustc: don't clone a type that is copy
librustc_incremental: use faster vector initialization
librustc_typeck: don't clone a type that is copy
librustdoc: don't create a vector where a slice will do
Some code fails when doing a full build but does not fail when only
emitting metadata. This commit makes sure compile_fail tests for such
code behave as expected, that is, the test succeeds because the
compilation fails.
On the backend, rustdoc now emits `paths` entries to a crate's search
index for struct-like enum variants, and index items of type structfield
which belong to such variants point to their variant parents in the
`paths` table, rather than their enum grandparents. The path entry for
a variant is the fully qualified module path plus the enum name.
On the frontend, the search code recognizes structfields belonging to
structlike variants in the `paths` table and re-constructs the URL to
the field's anchor on the enum documentation page.
closes#16017
rustdoc: Fix re-exporting primitive types
* Generate links to the primitive type docs for re-exports.
* Don't ICE on cross crate primitive type re-exports.
* Make primitive type re-exports show up cross crate.
Fixes#67646Closes#67972
r? @GuillaumeGomez
* Generate links to the primitive type docs for re-exports.
* Don't ICE on cross crate primitive type re-exports.
* Make primitive type re-exports show up cross crate.
Implement `?const` opt-out for trait bounds
For now, such bounds are treated exactly the same as unprefixed ones in all contexts. [RFC 2632](https://github.com/rust-lang/rfcs/pull/2632) does not specify whether such bounds are forbidden outside of `const` contexts, so they are allowed at the moment.
Prior to this PR, the constness of a trait bound/impl was stored in `TraitRef`. Now, the constness of an `impl` is stored in `ast::ItemKind::Impl` and the constness of a bound in `ast::TraitBoundModifer`. Additionally, constness of trait bounds is now stored in an additional field of `ty::Predicate::Trait`, and the combination of the constness of the item along with any `TraitBoundModifier` determines the constness of the bound in accordance with the RFC. Encoding the constness of impls at the `ty` level is left for a later PR.
After a discussion in \#wg-grammar on Discord, it was decided that the grammar should not encode the mutual exclusivity of trait bound modifiers. The grammar for trait bound modifiers remains `[?const] [?]`. To encode this, I add a dummy variant to `ast::TraitBoundModifier` that is used when the syntax `?const ?` appears. This variant causes an error in AST validation and disappears during HIR lowering.
cc #67794
r? @oli-obk
