clarify `must_produce_diag` ICE for debugging
We have a sanity check to ensure the expensive `trimmed_def_paths` functions are called only when producing diagnostics, and not e.g. on the happy path. The panic often happens IME during development because of randomly printing stuff, causing an ICE if no diagnostics were also emitted.
I have this change locally but figured it could be useful to others, so this PR clarifies the message when this happens during development.
The output currently looks like this by default; it's a bit confusing with words missing:
```
thread 'rustc' panicked at compiler/rustc_errors/src/lib.rs:628:17:
must_produce_diag: `trimmed_def_paths` called but no diagnostics emitted; `with_no_trimmed_paths` for debugging. called at: disabled backtrace
stack backtrace:
0: 0x7ffff79570f6 - std::backtrace_rs::backtrace::libunwind::trace::h33576c57327a3cea
at .../library/std/src/../../backtrace/src/backtrace/libunwind.rs:116:5
1: 0x7ffff79570f6 - std::backtrace_rs::backtrace::trace_unsynchronized::h7972a09393b420db
at .../library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
2: 0x7ffff79570f6 - std::sys::backtrace::_print_fmt::hae8c5bbfbf7a8322
at .../library/std/src/sys/backtrace.rs:66:9
3: 0x7ffff79570f6 - <std::sys::backtrace::BacktraceLock::print::DisplayBacktrace as core::fmt::Display>::fmt::h1fd6a7a210f5b535
...
```
The new output mentions how to get more information and locate where the `with_no_trimmed_paths` call needs to be added.
1. By default, backtraces are disabled:
```
thread 'rustc' panicked at compiler/rustc_errors/src/lib.rs:642:17:
`trimmed_def_paths` called, diagnostics were expected but none were emitted. Use `with_no_trimmed_paths` for debugging. Backtraces are currently disabled: set `RUST_BACKTRACE=1` and re-run to see where it happened.
stack backtrace:
0: 0x7ffff79565f6 - std::backtrace_rs::backtrace::libunwind::trace::h33576c57327a3cea
...
```
2. With backtraces enabled:
```
thread 'rustc' panicked at compiler/rustc_errors/src/lib.rs:642:17:
`trimmed_def_paths` called, diagnostics were expected but none were emitted. Use `with_no_trimmed_paths` for debugging. This happened in the following `must_produce_diag` call's backtrace:
0: <rustc_errors::DiagCtxtHandle>::set_must_produce_diag
at .../compiler/rustc_errors/src/lib.rs:1133:58
1: <rustc_session::session::Session>::record_trimmed_def_paths
at .../compiler/rustc_session/src/session.rs:327:9
2: rustc_middle::ty::print::pretty::trimmed_def_paths
at .../compiler/rustc_middle/src/ty/print/pretty.rs:3351:5
...
```
A `\n` could be added here or there, but it didn't matter much whenever I hit this case with the new message.
Make precise capturing suggestion machine-applicable only if it has no APITs
cc https://github.com/rust-lang/rust/issues/132932
The only case where this suggestion is not machine-applicable is when we suggest turning arg-position impl trait into type parameters, which may expose type parameters that were not turbofishable before.
Triagebot: Consolidate the T-compiler ad hoc assignment groups
https://github.com/rust-lang/compiler-team/issues/757
1. Inline compiler-team and compiler-team-contributors into compiler
2. Sort members alphabetically
Proper support for cross-crate recursive const stability checks
~~Stacked on top of https://github.com/rust-lang/rust/pull/132492; only the last three commits are new.~~
In a crate without `staged_api` but with `-Zforce-unstable-if-unmarked`, we now subject all functions marked with `#[rustc_const_stable_indirect]` to recursive const stability checks. We require an opt-in so that by default, a crate can be built with `-Zforce-unstable-if-unmarked` and use nightly features as usual. This property is recorded in the crate metadata so when a `staged_api` crate calls such a function, it sees the `#[rustc_const_stable_indirect]` and allows it to be exposed on stable. This, finally, will let us expose `const fn` from hashbrown on stable.
The second commit makes const stability more like regular stability: via `check_missing_const_stability`, we ensure that all publicly reachable functions have a const stability attribute -- both in `staged_api` crates and `-Zforce-unstable-if-unmarked` crates. To achieve this, we move around the stability computation so that const stability is computed after regular stability is done. This lets us access the final result of the regular stability computation, which we use so that `const fn` can inherit the regular stability (but only if that is "unstable"). Fortunately, this lets us get rid of an `Option` in `ConstStability`.
This is the last PR that I have planned in this series.
r? `@compiler-errors`
Proper support for cross-crate recursive const stability checks
~~Stacked on top of https://github.com/rust-lang/rust/pull/132492; only the last three commits are new.~~
In a crate without `staged_api` but with `-Zforce-unstable-if-unmarked`, we now subject all functions marked with `#[rustc_const_stable_indirect]` to recursive const stability checks. We require an opt-in so that by default, a crate can be built with `-Zforce-unstable-if-unmarked` and use nightly features as usual. This property is recorded in the crate metadata so when a `staged_api` crate calls such a function, it sees the `#[rustc_const_stable_indirect]` and allows it to be exposed on stable. This, finally, will let us expose `const fn` from hashbrown on stable.
The second commit makes const stability more like regular stability: via `check_missing_const_stability`, we ensure that all publicly reachable functions have a const stability attribute -- both in `staged_api` crates and `-Zforce-unstable-if-unmarked` crates. To achieve this, we move around the stability computation so that const stability is computed after regular stability is done. This lets us access the final result of the regular stability computation, which we use so that `const fn` can inherit the regular stability (but only if that is "unstable"). Fortunately, this lets us get rid of an `Option` in `ConstStability`.
This is the last PR that I have planned in this series.
r? `@compiler-errors`
Delete the `cfg(not(parallel))` serial compiler
Since it's inception a long time ago, the parallel compiler and its cfgs have been a maintenance burden. This was a necessary evil the allow iteration while not degrading performance because of synchronization overhead.
But this time is over. Thanks to the amazing work by the parallel working group (and the dyn sync crimes), the parallel compiler has now been fast enough to be shipped by default in nightly for quite a while now.
Stable and beta have still been on the serial compiler, because they can't use `-Zthreads` anyways.
But this is quite suboptimal:
- the maintenance burden still sucks
- we're not testing the serial compiler in nightly
Because of these reasons, it's time to end it. The serial compiler has served us well in the years since it was split from the parallel one, but it's over now.
Let the knight slay one head of the two-headed dragon!
#113349
Note that the default is still 1 thread, as more than 1 thread is still fairly broken.
cc `@onur-ozkan` to see if i did the bootstrap field removal correctly, `@SparrowLii` on the sync parts
Since it's inception a long time ago, the parallel compiler and its cfgs
have been a maintenance burden. This was a necessary evil the allow
iteration while not degrading performance because of synchronization
overhead.
But this time is over. Thanks to the amazing work by the parallel
working group (and the dyn sync crimes), the parallel compiler has now
been fast enough to be shipped by default in nightly for quite a while
now.
Stable and beta have still been on the serial compiler, because they
can't use `-Zthreads` anyways.
But this is quite suboptimal:
- the maintenance burden still sucks
- we're not testing the serial compiler in nightly
Because of these reasons, it's time to end it. The serial compiler has
served us well in the years since it was split from the parallel one,
but it's over now.
Let the knight slay one head of the two-headed dragon!
move all mono-time checks into their own folder, and their own query
The mono item collector currently also drives two mono-time checks: the lint for "large moves", and the check whether function calls are done with all the required target features.
Instead of doing this "inside" the collector, this PR refactors things so that we have a new `rustc_monomorphize::mono_checks` module providing a per-instance query that does these checks. We already have a per-instance query for the ABI checks, so this should be "free" for incremental builds. Non-incremental builds might do a bit more work now since we now have two separate MIR visits (in the collector and the mono-time checks) -- but one of them is cached in case the MIR doesn't change, which is nice.
This slightly changes behavior of the large-move check since the "move_size_spans" deduplication logic now only works per-instance, not globally across the entire collector.
Cc `@saethlin` since you're also doing some work related to queries and caching and monomorphization, though I don't know if there's any interaction here.
Make sure to ignore elided lifetimes when pointing at args for fulfillment errors
See the comment I left in the code.
---
If we have something like:
```
fn foo<'a, T: 'a + BoundThatIsNotSatisfied>() {}
```
And the user turbofishes just the type args:
```
foo::<()>();
```
Then if we try pointing at `()` (i.e. the type argument for `T`), we don't actually consider the possibility that the lifetimes may have been left out of the turbofish. We try indexing incorrectly into the HIR args, and bail on the suggestion.
Consolidate type system const evaluation under `traits::evaluate_const`
Part of #130704Fixes#128232Fixes#118545
Removes `ty::Const::{normalize_internal, eval_valtree}` and `InferCtxt::(try_)const_eval_resolve`, consolidating the associated logic into `evaluate_const` in `rustc_trait_selection`. This results in an API for `ty::Const` that is free of any normalization/evaluation functions that would be incorrect to use under `min_generic_const_args`/`associated_const_equality`/`generic_const_exprs` or, more generally, that would be incorrect to use in the presence of generic type system constants.
Moving this logic to `rustc_trait_selection` and out of `rustc_middle` is also a pre-requisite for ensuring that we do not evaluate constants whose where clauses do not hold.
From this point it should be relatively simple (hah) to implement more complex normalization of type system constants such as: checking wf'ness before invoking CTFE machinery, or being able to normalize const aliases that still refer to generic parameters.
r? `@compiler-errors`
Update grammar in std::cell docs.
Using "having" in both the leading sentence and the bullets is unnecessary.
It makes it read as "it is only possible to have having several immutable...".
test(configure): cover `parse_args` in `src/bootstrap/configure.py`
I was reading `src/bootstrap/configure.py` and `parse_args` function there seems complex. So I added some tests to cover it and prevent regressions.
Feature gate yield expressions not in 2024
This changes it so that yield expressions are no longer allowed in the 2024 edition without a feature gate. We are currently only reserving the `gen` keyword in the 2024 edition, and not allowing anything else to be implicitly enabled by the edition.
In practice this doesn't have a significant difference since yield expressions can't really be used outside of coroutines or gen blocks, which have their own feature gates. However, it does affect what is accepted pre-expansion, and I would feel more comfortable not allowing yield expressions.
I believe the stabilization process for gen blocks or coroutines will not need to check the edition here, so this shouldn't ever be needed.
Remove attributes from generics in built-in derive macros
Related issue #132561
Removes all attributes from generics in the expanded implementations of built-in derive macros.
Rollup of 8 pull requests
Successful merges:
- #132487 (Provide placeholder generics for traits in "no method found for type parameter" suggestions)
- #132627 (cleanup: Remove outdated comment of `thir_body`)
- #132653 (Don't use `maybe_unwrap_block` when checking for macro calls in a block expr)
- #132793 (Update mdbook to 0.4.42)
- #132847 (elem_offset / subslice_range: use addr() instead of 'as usize')
- #132869 (split up the first paragraph of doc comments for better summaries)
- #132929 (Check for null in the `alloc_zeroed` example)
- #132933 (Make sure that we suggest turbofishing the right type arg for never suggestion)
r? `@ghost`
`@rustbot` modify labels: rollup
Make sure that we suggest turbofishing the right type arg for never suggestion
I had a bug where rust would suggest the wrong arg to turbofish `()` if there were any early-bound lifetimes...
r? WaffleLapkin
split up the first paragraph of doc comments for better summaries
used `./x clippy -Aclippy::all '-Wclippy::too_long_first_doc_paragraph' library/core library/alloc` to find these issues.
Update mdbook to 0.4.42
This updates mdbook to 0.4.42
Changelog: https://github.com/rust-lang/mdBook/blob/master/CHANGELOG.md#mdbook-0441
There were some significant changes that I would like to get early testing on.
This also updates rust-by-example which was required due to an update to the theme file.
Don't use `maybe_unwrap_block` when checking for macro calls in a block expr
Fixes#131915
Using `maybe_unwrap_block` to determine if we are looking at a `{ mac_call!{} }` will fail sometimes as `mac_call!{}` could be a `StmtKind::MacCall` not a `StmtKind::Expr`. This caused the def collector to think that `{ mac_call!{} }` was a non-trivial const argument and create a definition for it even though it should not.
r? `@compiler-errors` cc `@camelid`
cleanup: Remove outdated comment of `thir_body`
When typeck fails, `thir_body` returns `ErrorGuaranteed` rather than empty body.
No other code follows this outdated description except `check_unsafety`, which is also cleaned up in this PR.
