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
This clarifies the explanation of why this is not allowed and also what to do instead.
Fixes 62071
PS There was suggestion of adding a link to the book. I did not yet do that, but if desired that could be added.
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`
On Unix the limits can be gargantuan anyway so we're pretty
unlikely to hit them, but might still exceed it.
We consult ARG_MAX here to get an estimate.
