Rollup of 5 pull requests
Successful merges:
- #102143 (Recover from struct nested in struct)
- #102178 (bootstrap: the backtrace feature is stable, no need to allow it any more)
- #102197 (Stabilize const `BTree{Map,Set}::new`)
- #102267 (Don't set RUSTC in the bootstrap build script)
- #102270 (Remove benches from `rustc_middle`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Remove benches from `rustc_middle`
These benches benchmark rust langauge features and not the compiler, so they seem to be in the wrong place here. They also all take <1ns, making them pretty useless. Looking at their git history, they just seem to have been carried around for many, many years. This commit ends their journey.
Stabilize const `BTree{Map,Set}::new`
The FCP was completed in #71835.
Since `len` and `is_empty` are not const stable yet, this also creates a new feature for them since they previously used the same `const_btree_new` feature.
`Cursor` keeps track of the position within the current token. But it
uses confusing names that don't make it clear that the "length consumed"
is just within the current token.
This commit renames things to make this clearer.
`Cursor` is currently hidden, and the main tokenization path uses
`rustc_lexer::first_token` which involves constructing a new `Cursor`
for every single token, which is weird. Also, `first_token` also can't
handle empty input, so callers have to check for that first.
This commit makes `Cursor` public, so `StringReader` can contain a
`Cursor`, which results in a simpler structure. The commit also changes
`StringReader::advance_token` so it returns an `Option<Token>`,
simplifying the the empty input case.
`TokenTreesReader` wraps a `StringReader`, but the `into_token_trees`
function obscures this. This commit moves to a more straightforward
control flow.
The spacing computation is done in two parts. In the first part
`next_token` and `bump` use `Spacing::Alone` to mean "preceded by
whitespace" and `Spacing::Joint` to mean the opposite. In the second
part `parse_token_tree_other` then adjusts the `spacing` value to mean
the usual thing (i.e. "is the following token joinable punctuation?").
This shift in meaning is very confusing and it took me some time to
understand what was going on.
This commit changes the first part to use a bool, and adds some
comments, which makes things much clearer.
Clean up (sub)diagnostic derives
The biggest chunk of this is unifying the parsing of subdiagnostic attributes (`#[error]`, `#[suggestion(...)]`, `#[label(...)]`, etc) between `Subdiagnostic` and `Diagnostic` type attributes as well as `Diagnostic` field attributes.
It also improves a number of proc macro diagnostics.
Waiting for #101558.
Use function pointers instead of macro-unrolled loops in rustc_query_impl
By making these standalone functions, we
a) allow making them extensible in the future with a new `QueryStruct`
b) greatly decrease the amount of code in each individual function, avoiding exponential blowup in llvm
Helps with https://github.com/rust-lang/rust/issues/96524. Based on https://github.com/rust-lang/rust/pull/101173; only the last commit is relevant.
r? `@cjgillot`
`parse_token_tree` is basically a match with four arms: `Eof`,
`OpenDelim`, `CloseDelim`, and "other". It has two call sites, and at
each call site one of the arms is unreachable. It's also not inlined.
This commit removes `parse_token_tree` by splitting it into four
functions and inlining them. This avoids some repeated conditional
tests and also some non-inlined function calls on the hot path.
* Remove the `float: right` fallback from the main header, which hasn't
been needed since IE11 support was dropped.
* Remove `in-band` from low-level headers, which hasn't been needed since
`.rightside` switched to `float: right` in
593d6d1cb1
* Remove unreachable `.in-band > code, .in-band > .code-header` CSS, since
the `in-band` class was attached to the `code-header` itself, not nested
directly below it.
* Use `rem` instead of `em` for code header margins.
* This results in a slight change in spacing around impls and item-info,
but since it makes it more consistent with the way methods are presented,
it's probably fine.
Neither require nor imply lifetime bounds on opaque type for well formedness
The actual hidden type can live arbitrarily longer than any individual lifetime and arbitrarily shorter than all but one of the lifetimes.
fixes#86218fixes#84305
This is a **breaking change** but it is a necessary soundness fix
