Rollup of 8 pull requests #139888
Closed
Rollup of 8 pull requests #139888
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…uilder` to `Config`
I feel like they are still wrong, but maybe less so .-. The `info:` was unhelpful -- we only use upstream in CI nowdays.
If checking succeeded, it's equivalent to successfully formatting.
Also refactors some of the crate name parsing code and adds unit tests Issue rust-lang#122349 Co-authored-by: León Orell Valerian Liehr <[email protected]>
Because it's equivalent to `#[rustc_mir(borrowck_graphviz_format)]`. It used to be distinct, but the distinction was removed in rust-lang@3233fb1.
In particular, `borrowck_graphviz_preflow` no longer exists.
…n, r=petrochenkov Stabilize `-Zdwarf-version` as `-Cdwarf-version` I propose stabilizing `-Zdwarf-version` as `-Cdwarf-version`. This PR adds a new `-Cdwarf-version` flag, leaving the unstable `-Z` flag as is to ease the transition period. The `-Z` flag will be removed in the future. # `-Zdwarf-version` stabilization report ## What is the RFC for this feature and what changes have occurred to the user-facing design since the RFC was finalized? No RFC/MCP, this flag was added in rust-lang#98350 and was not deemed large enough to require additional process. The tracking issue for this feature is rust-lang#103057. ## What behavior are we committing to that has been controversial? Summarize the major arguments pro/con. None that has been extensively debated but there are a few questions that could have been chosen differently: 1. What should the flag name be? The current flag name is very specific to DWARF. Other debuginfo formats exist (msvc's CodeView format or https://en.wikipedia.org/wiki/Stabs) so we could have chosen to generalize the flag name (`-{C,Z} debuginfo-version=dwarf-5` for example). While this would extend cleanly to support formats other than DWARF, there are some downsides to this design. Neither CodeView nor Stabs have specification or format versions so it's not clear what values would be supported beyond `dwarf-{2,3,4,5}` or `codeview`. We would also need to take care to ensure the name does not lead users to think they can pick a format other than one supported by the target. For instance, what would `--target x86_64-pc-windows-msvc -Cdebuginfo-version=dwarf-5` do? 2. What is the behavior when flag is used on targets that do not support DWARF? Currently, passing `-{C,Z} dwarf-version` on targets like `*-windows-msvc` does not do anything. It may be preferable to emit a warning alerting the user that the flag has no effect on the target platform. Alternatively, we could emit an error but this could be annoying since it would require the use of target specific RUSTFLAGS to use the flag correctly (and there isn't a way to target "any platform that uses DWARF" using cfgs). 3. Does the precompiled standard library potentially using a different version of DWARF a problem? I don't believe this is an issue as debuggers (and other such tools) already must deal with the possibility that an application uses different DWARF versions across its statically or dynamically linked libraries. ## Are there extensions to this feature that remain unstable? How do we know that we are not accidentally committing to those. No extensions per se, although future DWARF versions could be considered as such. At present, we validate the requested DWARF version is between 2 and 5 (inclusive) so new DWARF versions will not automatically be supported until the validation logic is adjusted. ## Summarize the major parts of the implementation and provide links into the code (or to PRs) - Targets define their preferred or default DWARF version: https://github.com/rust-lang/rust/blob/34a5ea911c56e79bd451c63f04ea2f5023d7d1a3/compiler/rustc_target/src/spec/mod.rs#L2369 - We use the target default but this can be overriden by `-{C,Z} dwarf-version` https://github.com/rust-lang/rust/blob/34a5ea911c56e79bd451c63f04ea2f5023d7d1a3/compiler/rustc_session/src/session.rs#L738 - The flag is validated https://github.com/rust-lang/rust/blob/34a5ea911c56e79bd451c63f04ea2f5023d7d1a3/compiler/rustc_session/src/session.rs#L1253-L1258 - When debuginfo is generated, we tell LLVM to use the requested value or the target default https://github.com/rust-lang/rust/blob/34a5ea911c56e79bd451c63f04ea2f5023d7d1a3/compiler/rustc_codegen_llvm/src/debuginfo/mod.rs#L106 ## Summarize existing test coverage of this feature - Test that we actually generate the appropriate DWARF version - https://github.com/rust-lang/rust/blob/master/tests/assembly/dwarf5.rs - https://github.com/rust-lang/rust/blob/master/tests/assembly/dwarf4.rs - Test that LTO with different DWARF versions picks the highest version - https://github.com/rust-lang/rust/blob/master/tests/assembly/dwarf-mixed-versions-lto.rs - Test DWARF versions 2-5 are valid while 0, 1 and 6 report an error - https://github.com/rust-lang/rust/blob/master/tests/ui/debuginfo/dwarf-versions.rs - Ensure LLVM does not report a warning when LTO'ing different DWARF versions together - https://github.com/rust-lang/rust/blob/master/tests/ui/lto/dwarf-mixed-versions-lto.rs ## Has a call-for-testing period been conducted? If so, what feedback was received? No call-for-testing has been conducted but Rust for Linux has been using this flag without issue. ## What outstanding bugs in the issue tracker involve this feature? Are they stabilization-blocking? All reported bugs have been resolved. ## Summarize contributors to the feature by name for recognition and assuredness that people involved in the feature agree with stabilization - Initial implementation in rust-lang#98350 by `@pcwalton` - Stop emitting `.debug_pubnames` and `.debug_pubtypes` when using DWARF 5 in rust-lang#117962 by `@weihanglo.` - Refactoring & cleanups (rust-lang#135739), fix LLVM warning on LTO with different DWARF versions (rust-lang#136659) and argument validation (rust-lang#136746) by `@wesleywiser` ## What FIXMEs are still in the code for that feature and why is it ok to leave them there? No FIXMEs related to this feature. ## What static checks are done that are needed to prevent undefined behavior? This feature cannot cause undefined behavior. We ensure the DWARF version is one of the supported values [here](https://github.com/rust-lang/rust/blob/34a5ea911c56e79bd451c63f04ea2f5023d7d1a3/compiler/rustc_session/src/session.rs#L1255-L1257). ## In what way does this feature interact with the reference/specification, and are those edits prepared? No changes to reference/spec, unstable rustc docs are moved to the stable book as part of the stabilization PR. ## Does this feature introduce new expressions and can they produce temporaries? What are the lifetimes of those temporaries? No. ## What other unstable features may be exposed by this feature? `-Zembed-source` requires use of DWARF 5 extensions but has its own feature gate. ## What is tooling support like for this feature, w.r.t rustdoc, clippy, rust-analzyer, rustfmt, etc.? No support needed for rustdoc, clippy, rust-analyzer, rustfmt or rustup. Cargo could expose this as an option in build profiles but I would expect the decision as to what version should be used would be made for the entire crate graph at build time rather than by individual package authors. cc-rs has support for detecting the presence of `-{C,Z} dwarf-version` in `RUSTFLAGS` and providing the corresponding flag to Clang/gcc (rust-lang/cc-rs#1395). --- Closes rust-lang#103057
Add unstable parsing of `--extern foo::bar=libbar.rlib` command line options This is a tiny step towards implementing the rustc side of support for implementing packages as optional namespaces (rust-lang#122349). We add support for parsing command line options like `--extern foo::bar=libbar.rlib` when the `-Z namespaced-crates` option is present. We don't do anything further with them. The next step is to plumb this down to the name resolver. This PR also generally refactors the extern argument parsing code and adds some unit tests to make it clear what forms should be accepted with and without the flag. cc `@epage` `@ehuss`
Disable combining LLD with external llvm-config When an external `llvm-config` is used, we don't really know anything about the external LLD, as we don't build it ourselves. Therefore, we probably shouldn't allow using `rust-lld` nor copy it to the target sysroot. Fixes: rust-lang#139477 CC `@cuviper` r? `@onur-ozkan`
Fix some tidy paper cuts The main thing this fixes is that currently, if you run `x t tidy` it will format ~6K files, even though it's supposed to format only modified files (whatever this is a useful optimization or not is besides the point). The problem is that `x t tidy` never writes the `rustfmt` stamp, so it always assumes `rustfmt` that was last used is outdated and we need to recheck everything. This PR fixes it by actually writing the stamp. There are also some minor tweaks to comments/diagnostics. cc `@Kobzol` this probably conflicts with rust-lang#138591. I didn't fix anything, just tried to document better the status quo. r? `@jieyouxu`
…ompiler-errors Fix wrong "move keyword" suggestion for async gen block Fixes rust-lang#139839. It was just missing a string comparison with `async gen`.
…=nnethercote Don't compute name of associated item if it's an RPITIT Use `Option::then` in favor of `Option::then_some` to not compute `AssocItem::name` if it fails the condition. Alternatively, I'd be open to changing this just to an `if`. Fixes rust-lang#139873 r? `@nnethercote`
Update books ## rust-lang/book 1 commits in 45f05367360f033f89235eacbbb54e8d73ce6b70..d33916341d480caede1d0ae57cbeae23aab23e88 2025-04-08 18:24:27 UTC to 2025-04-08 18:24:27 UTC - Ch01+ch02 after tech review (rust-lang/book#4329) ## rust-lang/edition-guide 2 commits in 1e27e5e6d5133ae4612f5cc195c15fc8d51b1c9c..467f45637b73ec6aa70fb36bc3054bb50b8967ea 2025-04-15 19:49:59 UTC to 2025-04-11 15:27:31 UTC - fix grammar errors (rust-lang/edition-guide#374) - remove the unused and deprecated `multilingual` field from `book.toml` (rust-lang/edition-guide#375) ## rust-lang/nomicon 2 commits in b4448fa406a6dccde62d1e2f34f70fc51814cdcc..0c10c30cc54736c5c194ce98c50e2de84eeb6e79 2025-04-09 01:54:42 UTC to 2025-04-07 20:22:31 UTC - Remove double wording in opaque type chapter (rust-lang/nomicon#487) - remove `rust-intrinsic` ABI (rust-lang/nomicon#485) ## rust-lang/reference 6 commits in 46435cd4eba11b66acaa42c01da5c80ad88aee4b..3340922df189bddcbaad17dc3927d51a76bcd5ed 2025-04-15 19:03:24 UTC to 2025-04-10 01:56:25 UTC - Add a new grammar renderer (rust-lang/reference#1787) - Misc. spelling fixes (rust-lang/reference#1785) - Fix std::ops links in range-expr (rust-lang/reference#1786) - traits.md: remove unusual formatting (rust-lang/reference#1784) - doc: add missing space (rust-lang/reference#1782) - spelling fix, Discrimants -> Discriminants (rust-lang/reference#1783)
…ompiler-errors `borrowck_graphviz_*` attribute tweaks A couple of small fixes to out-of-date things. r? `@davidtwco`
rustbot
added
A-run-make
rustbot
added
T-compiler
|
|
@bors r+ rollup=never p=5 |
bors
added
S-waiting-on-bors
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Apr 16, 2025
Rollup of 8 pull requests Successful merges: - rust-lang#136926 (Stabilize `-Zdwarf-version` as `-Cdwarf-version`) - rust-lang#139647 (Add unstable parsing of `--extern foo::bar=libbar.rlib` command line options) - rust-lang#139853 (Disable combining LLD with external llvm-config) - rust-lang#139867 (Fix some tidy paper cuts) - rust-lang#139871 (Fix wrong "move keyword" suggestion for async gen block) - rust-lang#139880 (Don't compute name of associated item if it's an RPITIT) - rust-lang#139884 (Update books) - rust-lang#139886 (`borrowck_graphviz_*` attribute tweaks) r? `@ghost` `@rustbot` modify labels: rollup
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
💔 Test failed - checks-actions |
bors
added
S-waiting-on-review
|
@bors retry |
bors
added
S-waiting-on-bors
|
I don't know how to kick out the current PR in favour of this one, so instead I'll close and make a new rollup that excludes #136926. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
-Zdwarf-versionas-Cdwarf-version#136926 (Stabilize-Zdwarf-versionas-Cdwarf-version)--extern foo::bar=libbar.rlibcommand line options #139647 (Add unstable parsing of--extern foo::bar=libbar.rlibcommand line options)borrowck_graphviz_*attribute tweaks #139886 (borrowck_graphviz_*attribute tweaks)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup