resolve: Give derive helpers highest priority during resolution
So they just shadow everything else and don't create ambiguity errors.
This matches the old pre-#64694 behavior most closely.
---
The change doesn't apply to this "compatibility" case
```rust
#[trait_helper] // The helper attribute is used before it introduced.
// Sadly, compiles on stable, supported via hacks.
// I plan to make a compatibility warning for this.
#[derive(Trait)]
struct S;
```
, such attributes still create ambiguities, but #64694 didn't change anything for this case.
Fixes https://github.com/rust-lang/rust/issues/66508
Fixes https://github.com/rust-lang/rust/issues/66525
Add JohnTitor to rustc-guide toolstate notification list
Add JohnTitor to rustc-guide toolstate notification list
Also, update org names of some books
r? @spastorino
Fix 'type annotations needed' error with opaque types
Related: #66426
This commit adds handling for opaque types during inference variable
fallback. Type variables generated from the instantiation of opaque
types now fallback to the opaque type itself.
Normally, the type variable for an instantiated opaque type is either
unified with the concrete type, or with the opaque type itself (e.g when
a function returns an opaque type by calling another function).
However, it's possible for the type variable to be left completely
unconstrained. This can occur in code like this:
```rust
pub type Foo = impl Copy;
fn produce() -> Option<Foo> {
None
}
```
Here, we'll instantatiate the `Foo` in `Option<Foo>` to a fresh type
variable, but we will never unify it with anything due to the fact
that we return a `None`.
This results in the error message:
```
type annotations needed: cannot resolve `_: std::marker::Copy
```
pointing at `pub type Foo = impl Copy`.
This message is not only confusing, it's incorrect. When an opaque type
inference variable is completely unconstrained, we can always fall back
to using the opaque type itself. This effectively turns that particular
use of the opaque type into a non-defining use, even if it appears in a
defining scope.
Suggest calling async closure when needed
When using an async closure as a value in a place that expects a future,
suggest calling the closure.
Fix#65923.
Misc CI improvements
This PR contains some misc improvements to our CI configuration:
* The environment variables for MinGW builders were greatly simplified, with just `CUSTOM_MINGW=1` to tell the install scripts to install the vendored copy. All the others (`MINGW_URL`, `MINGW_DIR`, `MINGW_ARCHIVE` and `MSYS_BITS`) are detected either from the builder name or the environment.
* Collecting CPU stats and running the build were moved into scripts.
* Toolstate scripts validation was previously a separate step, ran just when `IMAGE=mingw-check`. This moves the validation code inside the actual image.
* Vendored copies are now fetched from https://ci-mirrors.rust-lang.org instead of directly from the bucket.
r? @alexcrichton
Suggest `#[repr(C)]` instead of `#[repr(C, packed, ...)]`
The code was previously suggesting `#[repr(C, packed, ...)]` for incorrect uses of `repr` (e.g. `#[repr = "C"]`). This change suggests the usage of `#[repr(C)]` instead.
r? @estebank
Ref: #61286.
[mir-opt] Turn on the `ConstProp` pass by default
perf.rlo shows that running the `ConstProp` pass results in
across-the-board wins regardless of debug or opt complilation mode. As a
result, we're turning it on to get the compile time benefits.
Add outlives suggestions for some lifetime errors
This PR implements suggestion diagnostics for some lifetime mismatch errors. When the borrow checker finds that some lifetime 'a doesn't outlive some other lifetime 'b that it should outlive, then in addition to the current lifetime error, we also emit a suggestion for how to fix the problem by adding a bound:
- If a and b are normal named regions, suggest to add the bound `'a: 'b`
- If b is static, suggest to replace a with static
- If b also needs to outlive a, they must be the same, so suggest unifying them
We start with a simpler implementation that avoids diagnostic regression or implementation complexity:
- We only makes suggestions for lifetimes the user can already name (eg not closure regions or elided regions)
- For now, we only emit a help note, not an actually suggestion because it is significantly easier.
Finally, there is one hack: it seems that implicit regions in async fn are given the name '_ incorrectly. To avoid suggesting '_: 'x, we simply filter out such lifetimes by name.
For more info, see this internals thread:
https://internals.rust-lang.org/t/mechanical-suggestions-for-some-borrow-checker-errors/9049/3
TL;DR Make suggestions to add a `where 'a: 'b` constraint for some lifetime errors. Details are in the paper linked from the internals thread above.
r? @estebank
TODO
- [x] Clean up code
- [x] Only make idiomatic suggestions
- [x] don't suggest naming `&'a self`
- [x] rather than `'a: 'static`, suggest replacing `'a` with `'static`
- [x] rather than `'a: 'b, 'b: 'a`, suggest replacing `'a` with `'b` or vice versa
- [x] Performance (maybe need a perf run when this is closer to the finish line?)
- perf run was clean...
- EDIT: perf run seems to only check non-error performance... How do we check that error performance didn't regress?
- [x] Needs ui tests
- [x] Integrate the `help` message into the main lifetime `error`
Stabilize rustdoc theme options
Closes#54730
This PR stabilizes the `--themes` (now `--theme`) and `--theme-checker` (now `--check-theme`) options, for allowing users to add custom themes to their documentation.
Rustdoc includes two themes by default: `light` and `dark`. Using the `--theme` option, you can give rustdoc a CSS file to include as an extra theme for that render. Themes are named after the CSS file used, so using `--theme /path/to/your/custom-theme.css` will add a theme called `custom-theme` to the documentation.
Even though the CLI flag to add a theme is getting stabilized, there's no guarantee that a theme file will always have the same effect on documentation generated with future versions of rustdoc. To aid in ensuring that a theme will work, the flag `--check-theme` is also available, which compares the CSS rules defined by a custom theme against the ones used in the `light` theme. If the `light` theme defines a CSS rule that the custom theme does not, rustdoc will report an error. (Rustdoc also performs this check for themes given to `--theme`, but only reports a warning when a difference is found.)
Related: #66426
This commit adds handling for opaque types during inference variable
fallback. Type variables generated from the instantiatino of opaque
types now fallback to the opque type itself.
Normally, the type variable for an instantiated opaque type is either
unified with the concrete type, or with the opaque type itself (e.g when
a function returns an opaque type by calling another function).
However, it's possible for the type variable to be left completely
unconstrained. This can occur in code like this:
```rust
pub type Foo = impl Copy;
fn produce() -> Option<Foo> {
None
}
```
Here, we'll instantatiate the `Foo` in `Option<Foo>` to a fresh type
variable, but we will never unify it with anything due to the fact
that we return a `None`.
This results in the error message:
`type annotations needed: cannot resolve `_: std::marker::Copy``
pointing at `pub type Foo = impl Copy`.
This message is not only confusing, it's incorrect. When an opaque type
inference variable is completely unconstrained, we can always fall back
to using the opaque type itself. This effectively turns that particular
use of the opaque type into a non-defining use, even if it appears in a
defining scope.
