Use `rustc_type_ir` directly less in the codebase
cc https://github.com/rust-lang/rust/issues/138449
This is a somewhat opinionated bundle of changes that will make working on https://github.com/rust-lang/rust/issues/138449 more easy, since it cuts out the bulk of the changes that would be necessitated by the lint. Namely:
1. Fold `rustc_middle::ty::fold` and `rustc_middle::ty::visit` into `rustc_middle::ty`. This is because we already reexport some parts of these modules into `rustc_middle::ty`, and there's really no benefit from namespacing away the rest of these modules's functionality given how important folding and visiting is to the type layer.
2. Rename `{Decodable,Encodable}_Generic` to `{Decodable,Encodable}_NoContext`[^why], change it to be "perfect derive" (`synstructure::AddBounds::Fields`), use it throughout `rustc_type_ir` instead of `TyEncodable`/`TyDecodable`.
3. Make `TyEncodable` and `TyDecodable` derives use `::rustc_middle::ty::codec::TyEncoder` (etc) for its generated paths, and move the `rustc_type_ir::codec` module back to `rustc_middle::ty::codec` 🎉.
4. Stop using `rustc_type_ir` in crates that aren't "fundamental" to the type system, namely middle/infer/trait-selection. This amounted mostly to changing imports from `use rustc_type_ir::...` to `use rustc_middle::ty::...`, but also this means that we can't glob import `TyKind::*` since the reexport into `rustc_middle::ty::TyKind` is a type alias. Instead, use the prefixed variants like `ty::Str` everywhere -- IMO this is a good change, since it makes it more regularized with most of the rest of the compiler.
[^why]: `_NoContext` is the name for derive macros with no additional generic bounds and which do "perfect derive" by generating bounds based on field types. See `HashStable_NoContext`.
I'm happy to cut out some of these changes into separate PRs to make landing it a bit easier, though I don't expect to have much trouble with bitrot.
r? lcnr
Do not suggest using `-Zmacro-backtrace` for builtin macros
For macros that are implemented on the compiler, or that are annotated with `rustc_diagnostic_item`, which have arbitrary implementations from the point of view of the user and might as well be intrinsics, we do *not* mention the `-Zmacro-backtrace` flag. This includes `derive`s and standard macros like `panic!` and `format!`.
This PR adds a field to every `Span`'s `ExpnData` stating whether it comes from a builtin macro. This is determined by the macro being annotated with either `#[rustc_builtin_macro]` or `#[rustc_diagnostic_item]`. An alternative to using these attributes that already exist for other uses would be to introduce another attribute like `#[rustc_no_backtrace]` to have finer control on which macros are affected (for example, an error within `vec![]` now doesn't mention the backtrace, but one could make the case that it should). Ideally, instead of carrying this information in the `ExpnData` we'd instead try to query the `DefId` of the macro (that is already stored) to see if it is annotated in some way, but we do not have access to the `TyCtxt` from `rustc_errors`.
r? `@petrochenkov`
Make `Parser::parse_expr_cond` public
This allows usage in rustfmt and rustfmt forks.
I'm using this for custom macro formatting, see 30c83df9e1/src/parse/macros/html.rs (L57)
It would be great if this could be upstreamed so I don't need to rely on a fork.
Fix HIR printing of parameters
HIR pretty printing does the wrong thing for anonymous parameters, and there is no test coverage for it. This PR remedies both of those things.
r? ``@lcnr``
Refactor is_snake_case.
I wondered what the definition of this actually was, and found the original hard to read. I believe this change preserves the original behavior, but is hopefully clearer.
Improve post-merge workflow
Contains various fixes for the post-merge workflow implemented in https://github.com/rust-lang/rust/pull/138013, which were suggested on Zulip. This PR changes the grouping of test diffs and ignores doctests, as they are too noisy.
I'll post an example output (before/after this PR) in comments below.
r? ```@jieyouxu```
rustc_target: Add target features for LoongArch v1.1
This patch adds new target features for LoongArch v1.1:
* div32
* lam-bh
* lamcas
* ld-seq-sa
* scq
Update cargo
15 commits in ab1463d632528e39daf35f263e10c14cbe590ce8..6cf8267012570f63d6b86e85a2ae5627de52df9e
2025-03-08 01:45:05 +0000 to 2025-03-14 15:25:36 +0000
- feat(package): add --exclude-lockfile flag (rust-lang/cargo#15234)
- Redox OS is part of the unix family (rust-lang/cargo#15307)
- docs(ref): Mention `x.y.*` as a kind of version requirement to avoid. (rust-lang/cargo#15310)
- fix(run): Disambiguate bins from different packages that share a name (rust-lang/cargo#15298)
- cargo vendor: Add context which workspace failed to resolve (rust-lang/cargo#15297)
- docs(ref): Note that target-edition is deprecated (rust-lang/cargo#15292)
- refactor(toml): Centralize target descriptions (rust-lang/cargo#15291)
- docs(refs): Add `unsafe` to `extern` while using build scripts in Cargo Book (rust-lang/cargo#15294)
- Replace unmaintained humantime crate with jiff (rust-lang/cargo#15290)
- Add terminal integration via ANSI OSC 9;4 sequences (rust-lang/cargo#14615)
- feat: add completions for add --path (rust-lang/cargo#15288)
- Allow `term.progress.when` to default (rust-lang/cargo#15287)
- docs: spelling and grammar fixes (rust-lang/cargo#15284)
- chore(deps): update cargo-semver-checks to v0.40.0 (rust-lang/cargo#15282)
- Typo fixes (rust-lang/cargo#15280)
r? ghost
Pass `CI_JOB_DOC_URL` to Docker
Fix-up for https://github.com/rust-lang/rust/pull/136911. I always forget to pass new environment variables to Docker images.. 🤦♂️
r? `@marcoieni`
try-job: x86_64-fuchsia
Remove `RUN_CHECK_WITH_PARALLEL_QUERIES`
After https://github.com/rust-lang/rust/pull/132282, I'm pretty sure that this is simply useless? It just runs check with an empty config, lol.
CC `@onur-ozkan`
r? `@Noratrieb`
remove must_use from <*const T>::expose_provenance
`<*mut T>::expose_provenance` does not have this attribute, and in fact the function is documented to have a side-effect, so there are perfectly legitimate use-cases where the return value would be ignored.
Provide helpful diagnostics for shebang lookalikes
When `[` is not found after a `#!`, a note will be added to the exisiting error
```
error: expected `[`, found `/`
--> src/main.rs:2:3
|
2 | #!/usr/bin/env -S cargo +nightly -Zscript
| ^ expected `[`
|
= note: the token sequence `#!` here looks like the start of a shebang interpreter directive but it is not
= help: if you meant this to be a shebang interpreter directive, move it to the very start of the file
```
Fixes#137249
r? `@fmease`
uefi: helpers: Add DevicePathNode abstractions
- UEFI device path is a series of nodes layed out in a contiguous memory region. So it makes sense to use Iterator abstraction for modeling DevicePaths
- This PR has been split off from #135368 for easier review. The allow dead_code will be removed in #135368
cc `@nicholasbishop`
Remove an outdated line from a test comment
They *used* to not work, however this was fixed in the PR that added the test. I forgot to remove this line or possibly lost its removal while rebasing.
r? `@ehuss`
Remove usage of legacy scheme paths on RedoxOS
The `name:/path` path syntax is getting phased out[^1] in favor of `/scheme/name/path`. Also using `null:` is no longer necessary as `/dev/null` is available on Redox OS too.
[^1]: https://gitlab.redox-os.org/redox-os/rfcs/-/blob/master/text/0006-scheme-path.md
cc `@jackpot51`
EUV: fix place of deref pattern's interior's scrutinee
The place previously used here was that of the temporary holding the reference returned by `Deref::deref` or `DerefMut::deref_mut`. However, since the inner pattern of `deref!(inner)` expects the deref-target type itself, this would ICE when that type was inspected (e.g. by the EUV case for slice patterns). This adds a deref projection to fix that.
Since current in-tree consumers of EUV (upvar inference and clippy) don't care about Rvalues, the place could be simplified to `self.cat_rvalue(pat.hir_id, self.pat_ty_adjusted(subpat)?)` to save some cycles. I personally find EUV to be a bit fragile, so I've opted for pedantic correctness. Maybe a `HACK` comment would suffice though?
Fixes#125059
r? `@compiler-errors`
