-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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 7 pull requests #98656
Rollup of 7 pull requests #98656
Conversation
Signed-off-by: Yuki Okushi <jtitor@2k36.org>
… r=tmiasko Simplify memory ordering intrinsics This changes the names of the atomic intrinsics to always fully include their memory ordering arguments. ```diff - atomic_cxchg + atomic_cxchg_seqcst_seqcst - atomic_cxchg_acqrel + atomic_cxchg_acqrel_release - atomic_cxchg_acqrel_failrelaxed + atomic_cxchg_acqrel_relaxed // And so on. ``` - `seqcst` is no longer implied - The failure ordering on chxchg is no longer implied in some cases, but now always explicitly part of the name. - `release` is no longer shortened to just `rel`. That was especially confusing, since `relaxed` also starts with `rel`. - `acquire` is no longer shortened to just `acq`, such that the names now all match the `std::sync::atomic::Ordering` variants exactly. - This now allows for more combinations on the compare exchange operations, such as `atomic_cxchg_acquire_release`, which is necessary for rust-lang#68464. - This PR only exposes the new possibilities through unstable intrinsics, but not yet through the stable API. That's for [a separate PR](rust-lang#98383) that requires an FCP. Suffixes for operations with a single memory order: | Order | Before | After | |---------|--------------|------------| | Relaxed | `_relaxed` | `_relaxed` | | Acquire | `_acq` | `_acquire` | | Release | `_rel` | `_release` | | AcqRel | `_acqrel` | `_acqrel` | | SeqCst | (none) | `_seqcst` | Suffixes for compare-and-exchange operations with two memory orderings: | Success | Failure | Before | After | |---------|---------|--------------------------|--------------------| | Relaxed | Relaxed | `_relaxed` | `_relaxed_relaxed` | | Relaxed | Acquire | ❌ | `_relaxed_acquire` | | Relaxed | SeqCst | ❌ | `_relaxed_seqcst` | | Acquire | Relaxed | `_acq_failrelaxed` | `_acquire_relaxed` | | Acquire | Acquire | `_acq` | `_acquire_acquire` | | Acquire | SeqCst | ❌ | `_acquire_seqcst` | | Release | Relaxed | `_rel` | `_release_relaxed` | | Release | Acquire | ❌ | `_release_acquire` | | Release | SeqCst | ❌ | `_release_seqcst` | | AcqRel | Relaxed | `_acqrel_failrelaxed` | `_acqrel_relaxed` | | AcqRel | Acquire | `_acqrel` | `_acqrel_acquire` | | AcqRel | SeqCst | ❌ | `_acqrel_seqcst` | | SeqCst | Relaxed | `_failrelaxed` | `_seqcst_relaxed` | | SeqCst | Acquire | `_failacq` | `_seqcst_acquire` | | SeqCst | SeqCst | (none) | `_seqcst_seqcst` |
…kh726 Use typed indices in argument mismatch algorithm I kinda went overboard with the renames, but in general, "arg" is renamed to "expected", and "input" is renamed to "provided", and we use new typed indices to make sure we're indexing into the right sized array. Other drive-by changes: 1. Factor this logic into a new function, so we don't need to `break 'label` to escape it. 1. Factored out dependence on `final_arg_types`, which is never populated for arguments greater than the number of expected args. Instead, we just grab the final coerced expression type from `in_progress_typeck_results`. 1. Adjust the criteria we use to print (provided) type names, before we didn't suggest anything that had infer vars, but now we suggest thing that have infer vars but aren't `_`. ~Also, sorry in advance, I kinda want to backport this but I know I have folded in a lot of unnecessary drive-by changes that might discourage that. I would be open to brainstorming how to get some of these changes on beta at least.~ edit: Minimized the ICE-fixing changes to rust-lang#97557 cc `@jackh726` as author of rust-lang#92364, and `@estebank` as reviewer of the PR. fixes rust-lang#97484
…fix, r=Mark-Simulacrum Account for `-Z simulate-remapped-rust-src-base` when resolving remapped paths Discovered in rust-lang#97682, `-Z simulate-remapped-rust-src-base` only partially simulated the behavior of `remap-debuginfo = true`. While the flag successfully simulates the remapping when stdlib's `rmeta` file is loaded, the simulated prefix was not accounted for when the remapped path's local path was being discovered. This caused the flag to not fully simulate the behavior of `remap-debuginfo = true`, leading to inconsistent behaviors. This PR fixes rust-lang#97682 by also accounting for the simulated path.
…bank Fix trait object reborrow suggestion Fixes rust-lang#93596 Slightly generalizes the logic we use to suggest fix first implemented in rust-lang#95609, specifically when we have a `Sized` obligation that comes from a struct's unsized tail.
…rrors Add regression test for rust-lang#79224 Closes rust-lang#79224 r? `@compiler-errors` Signed-off-by: Yuki Okushi <jtitor@2k36.org>
…li-obk interpret: do not prune requires_caller_location stack frames quite so early rust-lang#87000 made the interpreter skip `caller_location` frames for its stacktraces and `cur_span`. However, those functions are used for much more than just panic reporting, and e.g. when Miri reports UB somewhere, it probably wants to point inside `caller_location` frames. (And if it did not, it would want to have its own logic to decide that, not be forced into it by the core interpreter engine.) This fixes some rare ICEs in Miri that say "we should never pop more than one frame at once". So let's remove all `caller_location` logic from the core interpreter, and instead move it to CTFE error reporting. This does not change user-visible behavior. That's the first commit. We might additionally want to change CTFE error reporting to treat panics differently from other errors: only prune `caller_location` frames for panics. The second commit does that. But honestly I am not sure if this is an improvement. r? ``@oli-obk``
…nostic-fixes, r=davidtwco Some borrowck diagnostic fixes 1. Remove some redundant `.as_ref` suggestion logic from borrowck, this has the consequence of also not suggesting `.as_ref` after `Option` methods, but (correctly) before. 2. Fix a bug where we were replacing a binding's name with a type. Instead, make it a note. This is somewhat incomplete. See `src/test/ui/borrowck/suggest-as-ref-on-mut-closure.rs` for more improvements.
@bors r+ rollup=never p=5 |
📌 Commit 25fb2b4 has been approved by |
☀️ Test successful - checks-actions |
Finished benchmarking commit (493c960): comparison url. Instruction count
Max RSS (memory usage)Results
CyclesResults
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression Footnotes |
Would be good to investigate this regression -- I'm suspecting #98277 myself as doc regressions typically point to trait solving and that seems like it could add a slight regression there, cc @compiler-errors May not be worth doing anything more that confirming that assumption, though on smaller benchmarks the regression is pretty large. |
i can put up a revert pr to check perf |
Some of the doc/check regressions look to be in metadata decoding, so I suspect it's more likely to be #97786. I'll put up a revert soon to check. |
Looks like #97786 was a major part of this rollup's regression indeed. What's the procedure to follow ? Leave a message on the PR (done), requesting improvements, or a revert, etc ? |
Successful merges:
-Z simulate-remapped-rust-src-base
when resolving remapped paths #97786 (Account for-Z simulate-remapped-rust-src-base
when resolving remapped paths)min_specialization
with default generic causes an ICE #79224)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup