Add a MIR pass manager (Taylor's Version)
The final draft of #91386 and #77665.
While the compile-time constraints in #91386 are cool, I decided on a more minimal approach for now. I want to explore phase constraints and maybe relative-ordering constraints in the future, though. This should preserve existing behavior **exactly** (please let me know if it doesn't) while making the following changes to the way we organize things today:
- Each `MirPhase` now corresponds to a single MIR pass. `run_passes` is not responsible for listing the correct MIR phase.
- `run_passes` no longer silently skips passes if the declared MIR phase is greater than or equal to the body's. This has bitten me multiple times. If you want this behavior, you can always branch on `body.phase` yourself.
- If your pass is solely to emit errors, you can use the `MirLint` interface instead, which gets a shared reference to `Body` instead of a mutable one. By differentiating the two, I hope to make it clearer in the short term where lints belong in the pipeline. In the long term perhaps we could enforce this at compile-time?
- MIR is no longer dumped for passes that aren't enabled, or for lints.
I tried to check that `-Zvalidate` still works correctly, since the MIR phase is now updated as soon as the associated pass is done, instead of at the end of all the passes in `run_passes`. However, it looks like `-Zvalidate` is broken with current nightlies anyways 😢 (it spits out a bunch of errors).
cc `@oli-obk` `@wesleywiser`
r? rust-lang/wg-mir-opt
std: Stabilize the `thread_local_const_init` feature
This commit is intended to follow the stabilization disposition of the
FCP that has now finished in #84223. This stabilizes the ability to flag
thread local initializers as `const` expressions which enables the macro
to generate more efficient code for accessing it, notably removing
runtime checks for initialization.
More information can also be found in #84223 as well as the tests where
the feature usage was removed in this PR.
Closes#84223
Keep spans for generics in `#[derive(_)]` desugaring
Keep the spans for generics coming from a `derive`d Item, so that errors
and suggestions have better detail.
Fix#84003.
Updated error message for accidental uses of derive attribute as a crate attribute
This partially fixes the original issue #89566 by adding derive to the list of invalid crate attributes and then providing an updated error message however I'm not sure how to prevent the resolution error message from emitting without causing the compiler to just abort when it finds an invalid crate attribute (which I'd prefer not to do so we can find and emit other errors).
`@petrochenkov` I have been told you may have some insight on why it's emitting the resolution error though honestly I'm not sure if we need to worry about fixing it as long as we can provide the invalid crate attribute error also (which happens first anyway)
Rollup of 7 pull requests
Successful merges:
- #90538 (Document how recursion is handled for `ty::Ty`)
- #90851 (Add unchecked downcast methods)
- #91209 (Implement ``@snapshot`` check for htmldocck)
- #91385 (Suggest the `pat_param` specifier before `|` on 2021 edition )
- #91478 (Remove incorrect newline from float cast suggestion)
- #91481 (Use let_else in some more places in rustc_lint)
- #91488 (Fix ICE when `yield`ing in function returning `impl Trait`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Fix ICE when `yield`ing in function returning `impl Trait`
Change an assert to a `delay_span_bug` and remove an unwrap, that should fix it.
Fixes#91477
rustdoc: Remove Clean impls for tuples
This PR removes all nine Clean impls on tuples, converting them to
functions instead.
The fact that these are impls causes several problems:
1. They are nameless, so it's unclear what they do.
2. It's hard to find where they're used apart from removing them and
seeing what errors occur (this applies to all Clean impls, not just
the tuple ones).
3. Rustc doesn't currently warn when impls are unused, so dead code
can accumulate easily (all Clean impls).
4. Their bodies often use tuple field indexing syntax (e.g., `self.1`)
to refer to their "arguments", which makes reading the code more
difficult.
As I noted, some of these problems apply to all Clean impls, but even
those problems are exacerbated by the tuple impls since they make
general understanding of the code harder.
Converting the impls to functions solves all four of these problems.
r? `@GuillaumeGomez`
This commit removes the first of nine Clean impls on tuples, converting
it to a function instead.
The fact that these are impls causes several problems:
1. They are nameless, so it's unclear what they do.
2. It's hard to find where they're used apart from removing them and
seeing what errors occur (this applies to all Clean impls, not just
the tuple ones).
3. Rustc doesn't currently warn when impls are unused, so dead code
can accumulate easily (all Clean impls).
4. Their bodies often use tuple field indexing syntax (e.g., `self.1`)
to refer to their "arguments", which makes reading the code more
difficult.
As I noted, some of these problems apply to all Clean impls, but even
those problems are exacerbated by the tuple impls since they make
general understanding of the code harder.
Converting the impls to functions solves all four of these problems.
Reintroduce `into_future` in `.await` desugaring
This is a reintroduction of the remaining parts from https://github.com/rust-lang/rust/pull/65244 that have not been relanded yet.
This isn't quite ready to merge yet. The last attempt was reverting due to performance regressions, so we need to make sure this does not introduce those issues again.
Issues #67644, #67982
/cc `@yoshuawuyts`
* Annotate `derive`d spans from the user's code with the appropciate context
* Add `Span::can_be_used_for_suggestion` to query if the underlying span
at the users' code
tidy run
update invalid crate attributes, improve error
update test outputs
de-capitalise error
update tests
Update invalid crate attributes, add help message
Update - generate span without using BytePos
Add correct dependancies
Update - generate suggestion without BytePos
Tidy run
update tests
Generate Suggestion without BytePos
Add all builtin attributes
add err builtin inner attr at top of crate
fix tests
add err builtin inner attr at top of crate
tidy fix
add err builtin inner attr at top of crate
Fix ICE #91268 by checking that the snippet ends with a `)`
Fix#91268
Previously it was assumed that the last character of `snippet` will be a `)`, so using `snippet.len() - 1` as an index should be safe. However as we see in the test, it is possible to enter that branch without a closing `)`, and it will trigger the panic if the last character happens to be multibyte.
The fix is to ensure that the snippet ends with `)`, and skip the suggestion otherwise.
rustdoc: preload fonts
Follow-up from #82315.
I noticed that font loading was so slow that even when loading from local disk, we get a flash of unstyled text (FOUT) followed by a reflow when the fonts load. With this change, we reliably get the appropriate fonts in the first render pass when loading locally, and we get it some of the time when loading from a website.
This only preloads woff2 versions. According to https://caniuse.com/?search=preload and https://caniuse.com/?search=woff2, all browsers that support preload also support woff2, so this is fine; we will never load two copies of a font.
Don't preload italic font faces because they aren't used on all pages.
Demo: https://rustdoc.crud.net/jsha/preload-fonts/std/string/struct.String.html
