`hir::Lifetime::ident` currently sometimes uses `kw::Empty` for elided
lifetimes and sometimes uses `kw::UnderscoreLifetime`, and the
distinction is used when creating some error suggestions, e.g. in
`Lifetime::suggestion` and `ImplicitLifetimeFinder::visit_ty`. I found
this *really* confusing, and it took me a while to understand what was
going on.
This commit replaces all uses of `kw::Empty` in `hir::Lifetime::ident`
with `kw::UnderscoreLifetime`. It adds a new field
`hir::Lifetime::is_path_anon` that mostly replaces the old
empty/underscore distinction and makes things much clearer.
Some other notable changes:
- Adds a big comment to `Lifetime` talking about permissable field
values.
- Adds some assertions in `new_named_lifetime` about what ident values
are permissible for the different `LifetimeRes` values.
- Adds a `Lifetime::new` constructor that does some checking to make
sure the `is_elided` and `is_anonymous` states are valid.
- `add_static_impl_trait_suggestion` now looks at `Lifetime::res`
instead of the ident when creating the suggestion. This is the one
case where `is_path_anon` doesn't replace the old empty/underscore
distinction.
- A couple of minor pretty-printing improvements.
HIR printing currently gets very little testing. This increases coverage
a bit, with a focus on lifetimes.
There are some FIXME comments for cases that are printed in a dubious
fashion. This PR won't address those; the point of adding this test is
to ensure that the subsequent commits don't hurt pretty-printing.
Add job duration changes to post-merge analysis report
This should help us observe large regressions in job duration changes.
I would also like to add quick links to GH jobs/workflow to the post-merge workflow, but for that I first need to store some CI metadata to the bootstrap metrics, to make it easier to lookup the corresponding GH workflows (otherwise we'd need to look them up by commit SHA, which would be much more complicated). The last commit adds this metadata. Once this PR is merged, and the metadata will be available in the metrics stored on S3, I'll send a follow-up PR that uses the metadata to add links to job names in the post-merge workflow report.
r? `@marcoieni`
Remove unneeded LLVM CI test assertions
The `download_ci_llvm` bootstrap test was checking implementation details of the LLVM CI download check, which isn't very useful. It was essentially testing "if function_that_checks_if_llvm_ci_is_available returns true, we enable CI LLVM", but the usage of the function was an implementation detail. After https://github.com/rust-lang/rust/pull/138704, the inner implementation has changed, so the test now breaks if LLVM is updated.
I don't think that it's very useful to test implementation details like this, without taking the outside git state into account. Ideally, we should mock the git state for the test, otherwise the test will randomly break when executed in environments which the test does not control (e.g. on CI when a LLVM change happens).
I only kept the part of the test that checks that LLVM CI isn't used when we specify `download-ci-llvm = false`, as that should hold under all conditions, CI/local, and all git states.
I also kept the `if-unchanged` assertion, but only on CI, and as a temporary measure. After https://github.com/rust-lang/rust/pull/138591, we should have a proper way of mocking the git state to make the test robust, and make it test what we actually want.
Fixes [this](https://github.com/rust-lang/rust/pull/138784#issuecomment-2751460456).
r? `@ghost`
Improve suggest construct with literal syntax instead of calling
Closing #138931
When constructing a structure through a format similar to calling a constructor, we can use verbose suggestions to hint at using literal syntax for clearer advice. The case of multiple fields is also considered here, provided that the field has the same number of arguments as CallExpr.
r? compiler
Report compiletest pass mode if forced
This is very non-obvious if it fails in PR CI, because the starting invocation is miles away from the final test suite outcome.
Clean up a few things in rustc_hir_analysis::check::region
Each commit is independent. They are all small clean-ups in rustc_hir_analysis::check::region.
Remove `kw::Empty` uses from `rustc_middle`.
There are several places in `rustc_middle` that check for an empty lifetime name. These checks appear to be totally unnecessary, because empty lifetime names aren't produced here. (Empty lifetime names *are* possible in `hir::Lifetime`. Perhaps there was some confusion between it and the `rustc_middle` types?)
This commit removes the `kw::Empty` checks.
r? `@lcnr`
expand: Leave traces when expanding `cfg` attributes
This is the same as https://github.com/rust-lang/rust/pull/138515, but for `cfg(true)` instead of `cfg_attr`.
The difference is that `cfg(true)`s already left "traces" after themselves - the `cfg` attributes themselves, with `expanded_inert_attrs` set to true, with full tokens, available to proc macros.
This is not a reasonably expected behavior, but it could not be removed without a replacement, because a [major rustdoc feature](https://github.com/rust-lang/rfcs/pull/3631) and a number of clippy lints rely on it. This PR implements a replacement.
This needs a crater run, because it changes observable behavior (in an intended way) - proc macros can no longer see expanded `cfg(true)` attributes.
(Some minor unnecessary special casing for `sym::cfg_attr` is also removed in this PR.)
r? `@nnethercote`
Introduces the `ChangeId` enum to allow suppressing `change_id` warnings.
Now, `ChangeId` supports both numeric values and the string literal `"ignore"`.
Numeric values behave as expected, while `"ignore"` is used to suppress warning messages.
rustdoc: Rearrange `Item`/`ItemInner`.
The `Item` struct is 48 bytes and contains a `Box<ItemInner>`;
`ItemInner` is 104 bytes. This is an odd arrangement. Normally you'd
have one of the following.
- A single large struct, which avoids the allocation for the `Box`, but
can result in lots of wasted space in unused parts of a container like
`Vec<Item>`, `HashSet<Item>`, etc.
- Or, something like `struct Item(Box<ItemInner>)`, which requires the
`Box` allocation but gives a very small Item size, which is good for
containers like `Vec<Item>`.
`Item`/`ItemInner` currently gets the worst of both worlds: it always
requires a `Box`, but `Item` is also pretty big and so wastes space in
containers. It would make sense to push it in one direction or the
other. #138916 showed that the first option is a regression for rustdoc,
so this commit does the second option, which improves speed and reduces
memory usage.
r? `@GuillaumeGomez`
Rollup of 10 pull requests
Successful merges:
- #130883 (Add environment variable query)
- #138624 (Add mipsel maintainer)
- #138672 (Avoiding calling queries when collecting active queries)
- #138935 (Update wg-prio triagebot config)
- #138946 (Un-bury chapters from the chapter list in rustc book)
- #138964 (Implement lint against using Interner and InferCtxtLike in random compiler crates)
- #138977 (Don't deaggregate InvocationParent just to reaggregate it again)
- #138980 (Collect items referenced from var_debug_info)
- #138985 (Use the correct binder scope for elided lifetimes in assoc consts)
- #138987 (Always emit `native-static-libs` note, even if it is empty)
r? `@ghost`
`@rustbot` modify labels: rollup
