Stop bare trait lint applying to macro call sites
Fixes#61963. Apologies for the delay with in fixing this. If anyone has a better idea how to detect this macro call site case, I'd be happy to fix this in a more robust, less hacky way.
r? @estebank
Fix cycle error with existential types
Fixes#61863
We now allow uses of `existential type`'s that aren't defining uses - that is, uses which don't constrain the underlying concrete type.
To make this work correctly, we also modify `eq_opaque_type_and_type` to not try to apply additional constraints to an opaque type. If we have code like this:
```rust
existential type Foo;
fn foo1() -> Foo { ... }
fn foo2() -> Foo { foo1() }
```
then `foo2` doesn't end up constraining `Foo`, which means that `foo2` will end up using the type `Foo` internally - that is, an actual `TyKind::Opaque`. We don't want to equate this to the underlying concrete type - we just need to enforce the basic equality constraint between the two types (here, the return type of `foo1` and the return type of `foo2`)
Define built-in macros through libcore
This PR defines built-in macros through libcore using a scheme similar to lang items (attribute `#[rustc_builtin_macro]`).
All the macro properties (stability, visibility, etc.) are taken from the source code in libcore, with exception of the expander function transforming input tokens/AST into output tokens/AST, which is still provided by the compiler.
The macros are made available to user code through the standard library prelude (`{core,std}::prelude::v1`), so they are still always in scope.
As a result **built-in macros now have stable absolute addresses in the library**, like `core::prelude::v1::line!()`, this is an insta-stable change.
Right now `prelude::v1` is the only publicly available absolute address for these macros, but eventually they can be moved into more appropriate locations with library team approval (e.g. `Clone` derive -> `core::clone::Clone`).
Now when built-in macros have canonical definitions they can be imported or reexported without issues (https://github.com/rust-lang/rust/issues/61687).
Other changes:
- You can now define a derive macro with a name matching one of the built-in derives (https://github.com/rust-lang/rust/issues/52269). This was an artificial restriction that could be worked around with import renaming anyway.
Known regressions:
- Empty library crate with a crate-level `#![test]` attribute no longer compiles without `--test`. Previously it didn't compile *with* `--test` or with the bin crate type.
Fixes https://github.com/rust-lang/rust/issues/61687
Fixes https://github.com/rust-lang/rust/issues/61804
r? @eddyb
Implement slow-path for FirstSets::first
When 2 or more sequences share the same span, we can't use the precomputed map
for their first set. So we compute it recursively.
Fixes#62831.
Introduce `as_deref` to Option
This is re-submission for #59628.
Renames `deref()` to `as_deref()` and adds `deref_mut()` impls and tests.
CC #50264
r? @Kimundi
(I picked you as you're the previous reviewer.)
Polonius: fix some cases of `killed` fact generation, and most of the `ui` test suite
Since basic Polonius functionality was re-enabled by @matthewjasper in #54468, some tests were still failing in the polonius compare-mode.
This PR fixes all but one test in the `ui` suite by:
- fixing some bugs in the fact generation code, related to the `killed` relation: Polonius would incorrectly reject some NLL-accepted code, because of these missing `killed` facts.
- ignoring some tests in the polonius compare-mode: a lot of those manually test the NLL or migrate mode, and the failures were mostly artifacts of the test revisions, e.g. that `-Z polonius` requires full NLLs. Some others were also both failing with NLL and succeeding with Polonius, which we can't encode in tests at the moment.
- blessing the output of some tests: whenever Polonius and NLL have basically the same errors, except for diagnostics differences, the Polonius output is blessed. Whenever we've advanced into a less experimental phase, we'll want to revisit these cases (much like we did on the NLL test suite last year) to specifically work on diagnostics.
Fact generation changes:
- we now kill loans on the destination place of `Call` terminators
- we now kill loans on the locals destroyed by `StorageDead`
- we now also handle assignments to projections: killing the loans on a either a deref-ed local, or the ones whose `borrowed_place` conflicts with the current place.
One failing test remains: an overflow during fact generation, on a case of polymorphic recursion (and which I'll continue investigating later).
This adds some tests for the fact generation changes, with some simple Polonius cases similar to the existing smoke tests, but also for some cases encountered in the wild (in the `rand` crate for example).
A more detailed write-up is available [here](https://hackmd.io/CjYB0fs4Q9CweyeTdKWyEg?view) with an explanation for each test failure, the steps taken to resolve it (as a commit in the current PR), NLL and Polonius outputs (and diff), etc.
Since they've worked on this before, and we've discussed some of these failures together:
r? @matthewjasper
Suggest trait bound on type parameter when it is unconstrained
Given
```
trait Foo { fn method(&self) {} }
fn call_method<T>(x: &T) {
x.method()
}
```
suggest constraining `T` with `Foo`.
Fix#21673, fix#41030.
