Rollup of 12 pull requests #150135
Merged
Rollup of 12 pull requests #150135
+1,252
−222
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
There are major questions remaining about the reentrancy that this allows. It doesn't have any users on github outside of a single project that uses it in a panic=abort project to show backtraces. It can still be emulated through #[alloc_error_handler] or set_alloc_error_hook depending on if you use the standard library or not. And finally it makes it harder to do various improvements to the allocator shim.
…o filtering Reading the manifest doesn't work when running in the context of the rust build system.
Using a defaulted `CodegenBackend` method that querying for zstd support should automatically print a safe value of `false` on any backend that doesn't specifically indicate the presence or absence of zstd.
Remove -Zoom=panic There are major questions remaining about the reentrancy that this allows. It doesn't have any users on github outside of a single project that uses it in a panic=abort project to show backtraces. It can still be emulated through `#[alloc_error_handler]` or `set_alloc_error_hook` depending on if you use the standard library or not. And finally it makes it harder to do various improvements to the allocator shim. With this PR the sole remaining symbol in the allocator shim that is not effectively emulating weak symbols is the symbol that prevents skipping the allocator shim on stable even when it would otherwise be empty because libstd + `#[global_allocator]` is used. Closes rust-lang#43596 Fixes rust-lang#126683
Make `--print=backend-has-zstd` work by default on any backend Using a defaulted `CodegenBackend` method that querying for zstd support should automatically print a safe value of `false` on any backend that doesn't specifically indicate the presence or absence of zstd. This should fix the compiletest failures reported in rust-lang#149666 (comment), which can occur when LLVM is not the default codegen backend.
…elmann
Remove uses of `cfg({any()/all()})`
~~This implements the followup warning suggested in rust-lang/rfcs#3695
~~Lint against an empty `cfg(any/all)`, suggest the boolean literal equivalents.~~
rust-lang#149791 (comment)
Tracking issue: rust-lang#131204
…let ... else return`
Remove `[no-mentions]` handler in the triagebot config
Overhaul filename handling for cross-compiler consistency This PR overhauls the way we handle filenames in the compiler and `rmeta` in order to achieve achieve cross-compiler consistency (ie. having the same path no matter if the filename was created in the current compiler session or is coming from `rmeta`). This is required as some parts of the compiler rely on consistent paths for the soundness of generated code (see rust-lang#148328). In order to achieved consistency multiple steps are being taken by this PR: - by making `RealFileName` immutable - by only having `SourceMap::to_real_filename` create `RealFileName` - currently `RealFileName` can be created from any `Path` and are remapped afterwards, which creates consistency issue - by also making `RealFileName` holds it's working directory, embeddable name and the remapped scopes - this removes the need for a `Session`, to know the current(!) scopes and cwd, which is invalid as they may not be equal to the scopes used when creating the filename In order for `SourceMap::to_real_filename` to know which scopes to apply `FilePathMapping` now takes the current remapping scopes to apply, which makes `FileNameDisplayPreference` and company useless and are removed. This PR is split-up in multiple commits (unfortunately not atomic), but should help review the changes. Unblocks rust-lang#147611 Fixes rust-lang#148328
* Add `llvm.x86.vcvtps2ph.128` * `cargo fmt` * Test `_mm_cvtps_ph`
…m, r=jdonszelmann Simplify how inline asm handles `MaybeUninit` This is just better, but this is also allows it to handle changes from rust-lang#149614 (i.e. `ManuallyDrop` containing `MaybeDangle`).
This synchronizes the list with the current state of `sysctl` on macOS “Tahoe” 26.2. r? @Amanieu
Rustfmt used to be optional for nightlies long ago, but it is now always present. Also rename rust-toolchain to rust-toolchain.toml.
…-branches, r=jdonszelmann `cfg_select!`: parse unused branches tracking issue: rust-lang#115585 Emit parse errors that are found in the branches that are not selected, like e.g. how `#[cfg(false)] { 1 ++ 2 }` still emits a parse error even though the expression is never used by the program. Parsing the unused branches was requested by T-lang rust-lang#149783 (comment).
…cturing, r=fmease
Suggest struct pattern when destructuring Range with .. syntax
implemented a new diagnostic in rustc_resolve to detect invalid range destructuring attempts (e.g., let start..end = range). The fix identifies when resolution fails for identifiers acting as range bounds specifically handling cases where bounds are parsed as expressions and suggests the correct struct pattern syntax (std::ops::Range { start, end }). This replaces confusing "cannot find value" errors with actionable help, verified by a new UI test covering various identifier names.
Fixes rust-lang#149777
…on, r=kobzol Generate macro expansion for rust compiler crates docs This enables the `--generate-macro-expansion` rustdoc flag, generating possibility to expand macros directly in source code pages (rust-lang#137229). Needed this new feature when I was working on rust-lang#149919 and I thought "why not enable it by default?". So here we go. Not too sure who to r? here so: r? ``@kobzol``
…r=petrochenkov Support recursive delegation This PR adds support for recursive delegations and is a part of the delegation feature rust-lang#118212. r? ``@petrochenkov``
std_detect: AArch64 Darwin: expose SME F16F16 and B16B16 features This synchronizes the list with the current state of `sysctl` on macOS “Tahoe” 26.2. r? ``@Amanieu``
…ivooeo tests/run-make-cargo/same-crate-name-and-macro-name: New regression test Closes rust-lang#71259 which just **E-needs-test**. See rust-lang#71259 (comment) for a good description of what we should test (which we do in this PR). The project we add fails with an old nightly without the fix: ```console $ cargo +nightly-2020-03-10 run Compiling consumer v0.1.0 (/home/martin/src/rust-same-crate-same-macro/tests/run-make-cargo/same-crate-name-and-macro-name/consumer) Finished dev [unoptimized + debuginfo] target(s) in 0.14s Running `target/debug/consumer` thread 'main' panicked at 'assertion failed: `(left == right)` left: `"version 1"`, right: `"version 2"`', src/main.rs:6:5 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace ``` and passes with a recent toolchain: ```console $ cargo run warning: /home/martin/src/rust-same-crate-same-macro/tests/run-make-cargo/same-crate-name-and-macro-name/consumer/Cargo.toml: no edition set: defaulting to the 2015 edition while the latest is 2024 warning: /home/martin/src/rust-same-crate-same-macro/tests/run-make-cargo/same-crate-name-and-macro-name/mylib_v1/Cargo.toml: no edition set: defaulting to the 2015 edition while the latest is 2024 warning: /home/martin/src/rust-same-crate-same-macro/tests/run-make-cargo/same-crate-name-and-macro-name/mylib_v2/Cargo.toml: no edition set: defaulting to the 2015 edition while the latest is 2024 Compiling mylib v2.0.0 (/home/martin/src/rust-same-crate-same-macro/tests/run-make-cargo/same-crate-name-and-macro-name/mylib_v2) Compiling mylib v1.0.0 (/home/martin/src/rust-same-crate-same-macro/tests/run-make-cargo/same-crate-name-and-macro-name/mylib_v1) Compiling consumer v0.1.0 (/home/martin/src/rust-same-crate-same-macro/tests/run-make-cargo/same-crate-name-and-macro-name/consumer) Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.14s Running `target/debug/consumer` ``` in other words, the test tests what it should and will catch regressions.
Fixed ICE for EII with multiple defaults due to duplicate definition in nameres r? ``@jieyouxu`` (since you looked at the other one) Fixes rust-lang#149982 Previously a [fix was proposed](rust-lang#149985) by ``@SATVIKsynopsis`` which I marked as co-author on the first commit for the test they contributed. I'm closing this previous PR. Duplicate definitions of EII defaults shouldn't be possible. I want to still panic on them, since I want to know when other bugs exist. However, in this case the duplicate was caused by something more subtle: both eiis have the same name, and as such a "duplicate definition" error is given. However, the compiler gracefully continues compiling despite that, assuming only one of the two EIIs is actually defined. Both defaults then name resolve, and find the same single remaining EII, and both register themselves to be its default, breaking the single-default assumption. The solution: I added a span-delayed-bug, to make sure we only panic if we hadn't previously had this duplicate definition name resolution error. Thanks to ``@SATVIKsynopsis`` for their attempt. Adding a diagnostic here could make some sense, but nonetheless I think this is the better solution here <3 Also thanks to ``@yaahc`` for debugging help, she made me understand the name resolution of the situation so much better and is just lovely in general :3 The last commit is something I tried during debugging, which felt like a relevant test to add (one where both eiis also have the same function name)
…enkov unstable.rs: fix typos in comments (implementatble -> implementable)
…field_access, r=JonathanBrouwer Port `#[rustc_lint_opt_deny_field_access]` to attribute parser r? ``@JonathanBrouwer``
…bjorn3 Subtree sync for rustc_codegen_cranelift Nothing too exciting since the last sync. r? ``@ghost`` ``@rustbot`` label +A-codegen +A-cranelift +T-compiler
rustbot
added
A-attributes
Contributor
Author
|
@bors r+ rollup=never p=1001 |
Collaborator
Collaborator
|
🌲 The tree is currently closed for pull requests below priority 1000. This pull request will be tested once the tree is reopened. |
bors
added
S-waiting-on-bors
Collaborator
Collaborator
|
☀️ Test successful - checks-actions |
Contributor
What is this?This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.Comparing ed0006a (parent) -> fcf67da (this PR) Test differencesShow 408 test diffsStage 0
Stage 1
Stage 2
(and 200 additional test diffs) Additionally, 108 doctest diffs were found. These are ignored, as they are noisy. Job group index
Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard fcf67da039f42e3905cf6f69e33304299c45149f --output-dir test-dashboardAnd then open Job duration changes
How to interpret the job duration changes?Job durations can vary a lot, based on the actual runner instance |
Collaborator
|
📌 Perf builds for each rolled up PR:
previous master: ed0006a7ba In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
Collaborator
|
Finished benchmarking commit (fcf67da): comparison URL. Overall result: ❌✅ regressions and improvements - no action needed@rustbot label: -perf-regression Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (primary 2.5%, secondary 2.7%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (secondary 4.0%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 481.444s -> 481.593s (0.03%) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
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:
str_as_strto more types #145933 (Expandstr_as_strto more types)cfg_select!: parse unused branches #149925 (cfg_select!: parse unused branches)#[rustc_lint_opt_deny_field_access]to attribute parser #150125 (Port#[rustc_lint_opt_deny_field_access]to attribute parser)Failed merges:
#[rustc_lint_untracked_query_information]and#[rustc_lint_diagnostics]to using attribute parsers #150127 (Port#[rustc_lint_untracked_query_information]and#[rustc_lint_diagnostics]to using attribute parsers)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup