-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rollup of 8 pull requests #122097
Closed
Closed
Rollup of 8 pull requests #122097
Conversation
This file contains 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
With rust 1.75 the absolute build path is embedding into '.rustc' section and which causes reproducibility issues. Detailed issue is here. rust-lang#120825 (comment) With this change the 'absolute path' changed back to '/rust/$hash' format.
This makes it much easier to know which test failed without having to wait for compiletest to completely finish running. Before: ``` Testing stage0 compiletest suite=ui mode=ui (x86_64-unknown-linux-gnu) running 15274 tests iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii 88/15274 iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii 176/15274 iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii 264/15274 iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii 352/15274 iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii 440/15274 iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii 528/15274 iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiFFiiiiiii ... ``` After: ``` Testing stage0 compiletest suite=ui mode=ui (x86_64-unknown-linux-gnu) running 15274 tests iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii 88/15274 iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii 176/15274 iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii 264/15274 iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii 352/15274 iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii 440/15274 iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii 528/15274 iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii [ui] tests/ui/associated-type-bounds/implied-in-supertrait.rs ... F [ui] tests/ui/associated-type-bounds/return-type-notation/basic.rs#next_with ... F iiiiiiiiiiiii ... ``` This serves a similar use case to the existing RUSTC_TEST_FAIL_FAST, but is on by default and as a result much more discoverable. We should consider unifying RUSTC_TEST_FAIL_FAST with the `--no-fail-fast` flag in the future for consistency and discoverability.
Previously, libtest would wait until all tests finished running to print the progress, which made it annoying to run many tests at once (since you don't know which have failed). Change it to print the names as soon as they fail. This also adds a test for the terse output; previously it was untested.
From `impl Into<DiagnosticMessage>` to `impl Into<Cow<'static, str>>`. Because these functions don't produce user-facing output and we don't want their strings to be translated.
This always produces zero offset, regardless of what the struct layout is. Originally, this may have been necessary in order to change the pointer type, but with opaque pointers, it is no longer necessary.
Currently it only checks calls to functions marked with `#[rustc_lint_diagnostics]`. This commit changes it to check calls to any function with an `impl Into<{D,Subd}iagMessage>` parameter. This greatly improves its coverage and doesn't rely on people remembering to add `#[rustc_lint_diagnostics]`. The commit also adds `#[allow(rustc::untranslatable_diagnostic)`] attributes to places that need it that are caught by the improved lint. These places that might be easy to convert to translatable diagnostics. Finally, it also: - Expands and corrects some comments. - Does some minor formatting improvements. - Adds missing `DecorateLint` cases to `tests/ui-fulldeps/internal-lints/diagnostics.rs`.
Prior to the previous commit, `#[rust_lint_diagnostics]` attributes could only be used on methods with an `impl Into<{D,Subd}iagMessage>` parameter. But there are many other nearby diagnostic methods (e.g. `Diag::span`) that don't take such a parameter and should have the attribute. This commit adds the missing attribute to these `Diag` methods. This requires adding some missing `#[allow(rustc::diagnostic_outside_of_impl)]` markers at call sites to these methods.
bootstrap/libtest: print test name eagerly on failure even with `verbose-tests=false` / `--quiet` Previously, libtest would wait until all tests finished running to print the progress, which made it annoying to run many tests at once (since you don't know which have failed). Change it to print the names as soon as they fail. This makes it much easier to know which test failed without having to wait for compiletest to completely finish running. Before: ``` Testing stage0 compiletest suite=ui mode=ui (x86_64-unknown-linux-gnu) running 15274 tests iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii 88/15274 iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii 176/15274 iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii 264/15274 iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii 352/15274 iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii 440/15274 iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii 528/15274 iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiFFiiiiiii ... ``` After: ``` Testing stage0 compiletest suite=ui mode=ui (x86_64-unknown-linux-gnu) running 15274 tests iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii 88/15274 iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii 176/15274 iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii 264/15274 iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii 352/15274 iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii 440/15274 iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii 528/15274 iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii [ui] tests/ui/associated-type-bounds/implied-in-supertrait.rs ... F [ui] tests/ui/associated-type-bounds/return-type-notation/basic.rs#next_with ... F iiiiiiiiiiiii ... ``` This serves a similar use case to the existing RUSTC_TEST_FAIL_FAST, but is on by default and as a result much more discoverable. We should consider unifying RUSTC_TEST_FAIL_FAST with the `--no-fail-fast` flag in the future for consistency and discoverability.
…=oli-obk,Nadrieril Change the documented implicit value of `-C instrument-coverage` to `=yes` The option-value parser for `-Cinstrument-coverage=` currently accepts the following stable values: - `all` (implicit value of plain `-Cinstrument-coverage`) - `yes`, `y`, `on`, `true` (undocumented aliases for `all`) - `off` (default; same as not specifying `-Cinstrument-coverage`) - `no`, `n`, `false`, `0` (undocumented aliases for `off`) I'd like to rearrange and re-document the stable values as follows: - `no` (default; same as not specifying `-Cinstrument-coverage`) - `n`, `off`, `false` (documented aliases for `no`) - `0` (undocumented alias for `no`) - `yes` (implicit value of plain `-Cinstrument-coverage`) - `y`, `on`, `true` (documented aliases for `yes`) - `all` (documented as *currently* an alias for `yes` that may change; discouraged but not deprecated) The main changes being: - Documented default value changes from `off` to `no` - Documented implicit value changes from `all` to `yes` - Other boolean aliases (`n`, `off`, `false`, `y`, `on`, `true`) are explicitly documented - `all` remains currently an alias for `yes`, but is explicitly documented as being able to change in the future - `0` remains an undocumented but stable alias for `no` - The actual behaviour of coverage instrumentation does not change # Why? The choice of `all` as the implicit value only really makes sense in the context of the unstable `except-unused-functions` and `except-unused-generics` values. That arrangement was fine for an unstable flag, but it's confusing for a stable flag whose only other stable value is `off`, and will only become more confusing if we eventually want to stabilize other fine-grained coverage option values. (Currently I'm not aware of any plans to stabilize other coverage option values, but that's why I think now is a fine time to make this change, well before anyone actually has to care about it.) For example, if we ever add support for opt-in instrumentation of things that are *not* instrumented by `-Cinstrument-coverage` by default, it will be very strange for the `all` value to not actually instrument all things that we know how to instrument. # Compatibility impact Because this is not a functional change, there is no immediate compatibility impact. However, changing the documented semantics of `all` opens up the possibility of future changes that could be considered retroactively breaking. I don't think this is going to be a big deal in practice, for a few reasons: - The exact behaviour of coverage instrumentation is allowed to change, so changing the behaviour of `all` is not a *stability-breaking* change, as long as it still exists and does something reasonable. - `-Cinstrument-coverage` is mainly used by tools or scripts that can be easily updated if necessary. It's unusual for users to pass the flag directly, because processing the profiler output is complicated enough that tools/scripts tend to be necessary anyway. - Most people who are using coverage are probably relying on `-Cinstrument-coverage` rather than explicitly passing `-Cinstrument-coverage=all`, so the number of users actually affected by this change is likely to be low, and plausibly zero.
avoid overlapping privacy suggestion for single nested imports Fixes rust-lang#114884 This PR aims to avoid confusion inside braces for import suggestions. r? `@petrochenkov`
…diagnostic-lint, r=davidtwco Rework `untranslatable_diagnostic` lint Currently it only checks calls to functions marked with `#[rustc_lint_diagnostics]`. This PR changes it to check calls to any function with an `impl Into<{D,Subd}iagnosticMessage>` parameter. This greatly improves its coverage and doesn't rely on people remembering to add `#[rustc_lint_diagnostics]`. It also lets us add `#[rustc_lint_diagnostics]` to a number of functions that don't have an `impl Into<{D,Subd}iagnosticMessage>`, such as `Diag::span`. r? `@davidtwco`
Suggest correct path in include_bytes! `include_bytes!` paths are relative, and I'm often not sure how nested is the `.rs` file that I'm editing, so I have to guess the number of `"../.."`. This change searches `..` and `../..` for the given file and offers corrected path as a suggestion. I wasn't sure how to get the right span, and how to properly escape it. ```text error: couldn't read src/file.txt: No such file or directory (os error 2) --> src/main.rs:2:13 | 2 | let x = include_bytes!("file.txt"); | ^^^^^^^^^^^^^^^----------^ | | | help: it's in a parent directory: `"../../file.txt"` ```
Removing absolute path in proc-macro With rust 1.75 the absolute build path name is embedding into proc-macro (.rustc section) and which causes reproducibility issues. Detailed issue description is here - rust-lang#120825 (comment) With this change the 'absolute path' changed back to '/rust/$hash' format as in earlier revisions.
…=petrochenkov Fix linting paths with qself in `unused_qualifications` Fixes rust-lang#121999 `resolve_qpath` ends up being called again with `qself` set to `None` to check trait items from fully qualified paths. To avoid this the lint is moved to a place that accounts for this already https://github.com/rust-lang/rust/blob/96561a8fd134e8f2b205769a4fca03b392d9f484/compiler/rustc_resolve/src/late.rs#L4074-L4088 r? ````@petrochenkov````
cleanup: remove zero-offset GEP This GEP would've been used to change the pointer type in the past, but after opaque pointers it's a no-op. I missed removing this in rust-lang#105545. Split out from rust-lang#121577.
rustbot
added
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
T-bootstrap
Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
T-libs
Relevant to the library team, which will review and decide on the PR/issue.
rollup
A PR which is a rollup
labels
Mar 6, 2024
@bors r+ rollup=never p=8 |
bors
added
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
and removed
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
labels
Mar 6, 2024
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Mar 6, 2024
…iaskrgr Rollup of 8 pull requests Successful merges: - rust-lang#113518 (bootstrap/libtest: print test name eagerly on failure even with `verbose-tests=false` / `--quiet`) - rust-lang#117199 (Change the documented implicit value of `-C instrument-coverage` to `=yes`) - rust-lang#121190 (avoid overlapping privacy suggestion for single nested imports) - rust-lang#121382 (Rework `untranslatable_diagnostic` lint) - rust-lang#121833 (Suggest correct path in include_bytes!) - rust-lang#121959 (Removing absolute path in proc-macro) - rust-lang#122038 (Fix linting paths with qself in `unused_qualifications`) - rust-lang#122051 (cleanup: remove zero-offset GEP) 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
Status: Awaiting review from the assignee but also interested parties.
and removed
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
labels
Mar 6, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
rollup
A PR which is a rollup
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
T-bootstrap
Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
T-libs
Relevant to the library team, which will review and decide on the PR/issue.
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:
verbose-tests=false
/--quiet
#113518 (bootstrap/libtest: print test name eagerly on failure even withverbose-tests=false
/--quiet
)-C instrument-coverage
to=yes
#117199 (Change the documented implicit value of-C instrument-coverage
to=yes
)untranslatable_diagnostic
lint #121382 (Reworkuntranslatable_diagnostic
lint)unused_qualifications
#122038 (Fix linting paths with qself inunused_qualifications
)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup