Increase spacing for suggestions in diagnostics
Make the spacing between the code snippet and verbose structured
suggestions consistent with note and help messages.
r? @Centril
libsyntax: Enhance documentation of the AST module
This PR enhances documentation state to the `libsyntax/ast.rs` (as initiative caused by [rustc-guide#474](https://github.com/rust-lang/rustc-guide/issues/474)), by adding:
- Module documentation.
- Doc-comments (and a bit of usual comments) in non-obvious (as for me) places.
- Minor style fixes to improve module readability.
rustc_typeck: don't record direct callees in generator_interior.
For expressions like `f(g().await)` we were recording `f` as needing to be kept in a temporary (and therefore be tracked by the generator type) across the suspend, even if a function/method path.
However, this is never needed, and can cause issues with complex function types (see #65244).
cc @Zoxc @nikomatsakis
This is a relic from earlier attempts at dataflow-based const validation
that attempted to do promotion at the same time. #63812 takes a
different approach: `IsNotPromotable` is no longer a `Qualif` and is
computed lazily instead of eagerly. As a result, there's no need for an
eager `TempPromotionResolver`, and we can use the only implementer of
`QualifResolver` directly instead of through a trait.
rustc_mir: double-check const-promotion candidates for sanity.
Previously, const promotion involved tracking information about the value in a MIR local (or any part of the computation leading up to that value), aka "qualifs", in a quite stateful manner, which is hard to extend to arbitrary CFGs without a dataflow pass.
However, the nature of the promotion we do is that it's effectively an SSA-like "tree" (or DAG, really), of assigned-once locals - which is how we can take them from the original MIR in the first place.
This structure means that the subset of the MIR responsible for computing any given part of a const-promoted value is readily analyzable by walking that tree/DAG.
This PR implements such an analysis in `promote_consts`, reusing the `HasMutInterior` / `NeedsDrop` computation from `qualify_consts`, but reimplementing the equivalent of `IsNotPromotable` / `IsNotImplicitlyPromotable`.
Eventually we should be able to remove `IsNotPromotable` / `IsNotImplicitlyPromotable` from `qualify_consts`, which will simplify @ecstatic-morse's dataflow-based const-checking efforts.
But currently this is mainly for a crater check-only run - it will compare the results from the old promotion collection and the new promotion validation and ICE if they don't match.
r? @oli-obk
This is leftover from a restructuring of lint registration for drivers;
it should now happen via the register_lints field on Config rather than
this function.
Passes LLVM codegen and Emscripten link-time flags for exception
handling if and only if the panic strategy is `unwind`. Sets the
default panic strategy for Emscripten targets to `unwind`. Re-enables
tests that depend on unwinding support for Emscripten, including
`should_panic` tests.
SGX: Clear additional flag on enclave entry
An attacker could set both the AC flag in CR0 as in rflags. This causes the enclave to perform an AEX upon a misaligned memory access, and an attacker learns some information about the internal enclave state.
The AC flag in rflags is copied from userspace upon an enclave entry. Upon AEX it is copied and later restored. This patch forces the rflag.AC bit to be reset right after an enter.
self-profiling: Update measureme to 0.4.0 and remove non-RAII methods from profiler.
This PR removes all non-RAII based profiling methods from `SelfProfilerRef` 🎉
It also delegates the `TimingGuard` implementation to `measureme`, now that that is available there.
r? @wesleywiser
Insurance policy in case `iter.size_hint()` lies.
Follow up to https://github.com/rust-lang/rust/pull/64949/files#r334235076.
(If the perf impact is bad we can use `debug_assert!` instead.)
The good news is that the UI tests pass locally so `iter.size_hint()` seems to be honest *thus far*.
On the other hand, with the status quo we do not have an insurance policy should that change in some case. This is problematic because a) this could possibly make some program be accepted which shouldn't, b) the compiler itself could have memory unsafety if the correctness of the iterator is assumed in `unsafe { ... }` code (even though the blame lies with the `unsafe { ... }` block in question.)
r? @RalfJung
cc @nnethercote
