prep work for using timely dataflow with NLL
Two major changes:
**Two-phase borrows are overhauled.** We no longer have two bits per borrow. Instead, we track -- for each borrow -- an (optional) "activation point". Then, for each point P where the borrow is in scope, we check where P falls relative to the activation point. If P is between the reservation point and the activation point, then this is the "reservation" phase of the borrow, else the borrow is considered active. This is simpler and means that the dataflow doesn't have to care about 2-phase at all, at last not yet.
**We no longer support using the MIR borrow checker without NLL.** It is going to be increasingly untenable to support lexical mode as we go forward, I think, and also of increasingly little value. This also exposed a few bugs in NLL mode due to increased testing.
r? @pnkfelix
cc @bobtwinkles
Implement Chalk lowering rule Normalize-From-Impl
This extends the Chalk lowering pass with the "Normalize-From-Impl" rule for generating program clauses from a trait definition as part of #49177.
r? @nikomatsakis
Stabilize x86/x86_64 SIMD
This commit stabilizes the SIMD in Rust for the x86/x86_64 platforms. Notably
this commit is stabilizing:
* The `std::arch::{x86, x86_64}` modules and the intrinsics contained inside.
* The `is_x86_feature_detected!` macro in the standard library
* The `#[target_feature(enable = "...")]` attribute
* The `#[cfg(target_feature = "...")]` matcher
Stabilization of the module and intrinsics were primarily done in
rust-lang-nursery/stdsimd#414 and the two attribute stabilizations are done in
this commit. The standard library is also tweaked a bit with the new way that
stdsimd is integrated.
Note that other architectures like `std::arch::arm` are not stabilized as part
of this commit, they will likely stabilize in the future after they've been
implemented and fleshed out. Similarly the `std::simd` module is also not being
stabilized in this commit, only `std::arch`. Finally, nothing related to `__m64`
is stabilized in this commit either (MMX), only SSE and up types and intrinsics
are stabilized.
Closes#29717Closes#44839Closes#48556
This commit stabilizes the SIMD in Rust for the x86/x86_64 platforms. Notably
this commit is stabilizing:
* The `std::arch::{x86, x86_64}` modules and the intrinsics contained inside.
* The `is_x86_feature_detected!` macro in the standard library
* The `#[target_feature(enable = "...")]` attribute
* The `#[cfg(target_feature = "...")]` matcher
Stabilization of the module and intrinsics were primarily done in
rust-lang-nursery/stdsimd#414 and the two attribute stabilizations are done in
this commit. The standard library is also tweaked a bit with the new way that
stdsimd is integrated.
Note that other architectures like `std::arch::arm` are not stabilized as part
of this commit, they will likely stabilize in the future after they've been
implemented and fleshed out. Similarly the `std::simd` module is also not being
stabilized in this commit, only `std::arch`. Finally, nothing related to `__m64`
is stabilized in this commit either (MMX), only SSE and up types and intrinsics
are stabilized.
Closes#29717Closes#44839Closes#48556
Update `?` repetition disambiguation.
**Do not merge** (yet)
This is a test implementation of some ideas from discussion in https://github.com/rust-lang/rust/issues/48075 . This PR
- disallows `?` repetition from taking a separator, since the separator is never used.
- disallows the use of `?` as a separator. This allows patterns like `$(a)?+` to match `+` and `a+` rather than `a?a?a`. This is a _breaking change_, but maybe that's ok? Perhaps a crater run is the right approach?
cc @durka @alexreg @nikomatsakis
The unstable-feature attribute requires an issue (neglecting it is
E0547), which gets used in the error messages. Unfortunately, there are
some cases where "0" is apparently used a placeholder where no issue
exists, directing the user to see the (nonexistent) issue #0. (It would
have been better to either let `issue` be optional—compare to how issue
is an `Option<u32>` in the feature-gate declarations in
libsyntax/feature-gate.rs—or actually require that an issue be created.)
Rather than endeavoring to change how `#[unstable]` works at this time
(given competing contributor and reviewer priorities), this simple patch
proposes the less-ambitious solution of just not adding the "(see
issue)" note when the number is zero.
Resolves#49983.
macros: Remove matching on "complex" nonterminals requiring AST comparisons
So, you can actually use nonterminals from outer macros in left hand side of nested macros and invocations of nested macros will try to match passed arguments to them.
```rust
macro outer($nt_item: item) {
macro inner($nt_item) {
struct S;
}
inner!($nt_item); // OK, `$nt_item` matches `$nt_item`
}
```
Why this is bad:
- We can't do this matching correctly. When two nonterminals are compared, the original tokens are lost and we have to compare AST fragments instead. Right now the comparison is done by `PartialEq` impls derived on AST structures.
- On one hand, AST loses information compared to original tokens (e.g. trailing separators and other simplifications done during parsing to AST), so we can produce matches that are not actually correct.
- On another hand derived `PartialEq` impls for AST structures don't make much sense in general and compare various auxiliary garbage like spans. For the argument nonterminal to match we should use literally the same token (possibly cloned) as was used in the macro LHS (as in the example above). So we can reject matches that are actually correct.
- Support for nonterminal matching is the only thing that forces us to derive `PartialEq` for all (!) AST structures. As I mentioned these impls are also mostly nonsensical.
This PR removes support for matching on all nonterminals except for "simple" ones like `ident`, `lifetime` and `tt` for which we have original tokens that can be compared.
After this is done I'll submit another PR removing huge number of `PartialEq` impls from AST and HIR structures.
This is an arcane feature and I don't personally know why would anyone use it, but the change should ideally go through crater.
We'll be able to support this feature again in the future when all nonterminals have original token streams attached to them in addition to (or instead of) AST fragments.
Hygiene 2.0: Avoid comparing fields by name
There are two separate commits here (not counting tests):
- The first one unifies named (`obj.name`) and numeric (`obj.0`) field access expressions in AST and HIR. Before field references in these expressions are resolved it doesn't matter whether the field is named or numeric (it's just a symbol) and 99% of code is common. After field references are resolved we work with
them by index for all fields (see the second commit), so it's again not important whether the field was named or numeric (this includes MIR where all fields were already by index).
(This refactoring actually fixed some bugs in HIR-based borrow checker where borrows through names (`S {
0: ref x }`) and indices (`&s.0`) weren't considered overlapping.)
- The second commit removes all by-name field comparison and instead resolves field references to their indices once, and then uses those resolutions. (There are still a few name comparisons in save-analysis, because save-analysis is weird, but they are made correctly hygienic).
Thus we are fixing a bunch of "secondary" field hygiene bugs (in borrow checker, lints).
Fixes https://github.com/rust-lang/rust/issues/46314
Rollup of 14 pull requests
Successful merges:
- #49525 (Use sort_by_cached_key where appropriate)
- #49575 (Stabilize `Option::filter`.)
- #49614 (in which the non-shorthand patterns lint keeps its own counsel in macros)
- #49665 (Small nits to make couple of tests pass on mips targets.)
- #49781 (add regression test for #16223 (NLL): use of collaterally moved value)
- #49795 (Properly look for uninhabitedness of variants in niche-filling check)
- #49809 (Stop emitting color codes on TERM=dumb)
- #49856 (Do not uppercase-lint #[no_mangle] statics)
- #49863 (fixed typo)
- #49857 (Fix "fp" target feature for AArch64)
- #49849 (Add --enable-debug flag to musl CI build script)
- #49734 (proc_macro: Generalize `FromIterator` impl)
- #49730 (Fix ICE with impl Trait)
- #48270 (Replace `structurally_resolved_type` in casts check.)
Failed merges:
Replace `structurally_resolved_type` in casts check.
The behaviour of `resolve_type_vars_if_possible` is simpler and infallible. Other minor refactorings.
I'm not sure if this is backwards compatible, in theory resolving obligations between two cast checks could solve a dependency between them, but I don't know if that's actually possible and it doesn't sound like something we'd want to support.
Blindly checkpoint status of NLL mode ui tests
This takes the next (and potentially final?) step with #48879.
Namely, this PR got things to the point where I can successfully run `compiletest` on `src/test/ui` with `--compile-mode=nll`.
Here are the main pieces of it:
1. To figure out how to even run `compiletest` normally on the ui directory, I ran `x.py test -vv`, and then looked for the `compiletest` invocation that mentioned `src/test/ui`.
2. I took the aforementioned `compiletest` invocation and used it, adding `--compile-mode=nll` to the end. It had 170 failing cases.
3. Due to #49855, I had to edit some of the tests so that they fail even under NLL, via `#[rustc_error]`. That's the first commit. (Then goto 2 to double-check no such tests remain.)
4. I took the generated `build/target/test/foo.stderr` file for every case that failed, and blindly copied it to `src/test/foo.nll.stderr`. That's the second commit.
5. Goto 2 until there were no failing cases.
6. Remove any stamp files, and re-run `x.py test` to make sure that the edits and new `.nll.stderr` files haven't broken the pre-existing test suite.
add regression test for #16223 (NLL): use of collaterally moved value
Adds regression test for https://github.com/rust-lang/rust/issues/16223 which NLL fixes.
The current downside of this test is that it uses the `#![feature(box_patterns)]` and I haven't come up with a proper test that only uses the `#![feature(nll)]` - however, I don't know if this is even possible to test without `#![feature(box_syntax)]` or `#![feature(box_patterns)]`.
NOTE: I was careful to make each change in a manner that preserves the
existing diagnostic output (usually by ensuring that no lines were
added or removed). This means that the resulting source files are not
as nice to read as they were at the start. But we will have to review
these cases by hand anyway as follow-up work, so cleanup could
reasonably happen then (or not at all).
Modify compile-fail/E0389 error message WIP
This fixes#47388
cc @nikomatsakis @estebank
r? @nikomatsakis
Certain ui tests were failing locally. I'll check if the same happens here too.
chalkify: Implement lowering rule Implied-Bound-From-Trait
For #49177.
TODO:
- [x] Implement where clauses besides trait and projection predicates
- [x] Is the output of the `lower_trait_higher_rank` test correct?
- [ ] Remove `Self::Trait` from the query `tcx.predicates_of(<trait_id>).predicates`
- [ ] Consider moving tests to compile-fail to make them more manageable
