- Notifications
You must be signed in to change notification settings - Fork 13.8k
Rollup of 7 pull requests #147715
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 #147715
Conversation
Thus avoiding a `RefCell`.
Where supported, VSX is a 64x128b register set which encompasses both the floating point and vector registers. In the type tests, xvsqrtdp is used as it is the only two-argument vsx opcode supported by all targets on llvm. If you need to copy a vsx register, the preferred way is "xxlor xt, xa, xa".
Implemented preserves_flags on powerpc by making it do nothing. This prevents having two different ways to mark `cr0` as clobbered. clang and gcc alias `cr0` to `cc`. The gcc inline documentation does not state what this does on powerpc* targets, but inspection of the source shows it is equivalent to condition register field `cr0`, so it should not be added.
Makes it clear that this represents `#[doc = "content"]`, but not `#[doc(hidden)]` (or other uses of the `#[doc(...)]` attribute).
…manieu Stabilise `rotate_left` and `rotate_right` in `[_]` as `const fn` items. Tracking issue: rust-lang#143812 Closes: rust-lang#143812 This PR stabilises the `const_slice_rotate` feature: ```rust impl<T> [T] { pub const fn rotate_left(&mut self, mid: usize); pub const fn rotate_right(&mut self, k: usize); } ``` No blockers or unresolved questions. FCP required. Courtesy of `@okaneco.`
…r=Amanieu Add vsx register support for ppc inline asm, and implement preserves_flag option This should address the last(?) missing pieces of inline asm for ppc: * Explicit VSX register support. ISA 2.06 (POWER7) added a 64x128b register overlay extending the fpr's to 128b, and unifies them with the vmx (altivec) registers. Implementations details within gcc/llvm percolate up, and require using the `x` template modifier. I have updated the inline asm to implicitly include this for vsx arguments which do not specify it. ~~Support for the gcc codegen backend is still a todo.~~ * Implement the `preserves_flags` option. All ABI's, and all ISAs store their flags in `cr`, and the carry bit lives inside `xer`. The other status registers hold sticky bits or control bits which do not affect branch instructions. There is some interest in the e500 (powerpcspe) port. Architecturally, it has a very different FP ISA, and includes a simd extension called SPR (which is not IBM's cell SPE). Notably, it does not have altivec/fpr/vsx registers. It also has an SPE accumulator register which its ABI marks as volatile, but I am not sure if the compiler uses it.
resolve: Use primitives for conditional mutability more consistently No bare `(Ref)Cell`s remain in `rustc_resolve`, only `Cm(Ref)Cell`s checking that nothing is modified during speculative resolution, and `Cache(Ref)Cell` aliases for cells that need to be migrated to mutexes/atomics. cc `@LorrensP-2158466`
…=JonathanBrouwer remove span calls from deprecated attribute checking r? `@JonathanBrouwer`
…ent, r=jdonszelmann Clairify docs for `AttributeKind::DocComment` Makes it clear that this represents `#[doc = "content"]`, but not `#[doc(hidden)]` (or other uses of the `#[doc(...)]` attribute). r? `@jdonszelmann`
Add myself to review rotation I'll try it out for a while, and see if I can keep up with things r? compiler
…nieu Clarify that UB will occur, not can/may in GlobalAlloc docs These doc comments start out very clear by saying the caller "must" or "has to" ensure something, but the end with some form of "otherwise undefined behavior may result" which sounds like it is implementation-defined and seems to conflict with the way the paragraph starts. Consistent phrasing makes it clearer that when the safety precondition is violated, UB is encountered. Some of the phrasing here is a bit awkward to me, I don't think we usually say "the behavior is undefined" `@RalfJung` right? But in either case I'm trying to be surgical in my edit here. r? Amanieu
@bors r+ rollup=never p=5 |
☀️ Test successful - checks-actions |
📌 Perf builds for each rolled up PR:
previous master: 235a4c083e In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
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 235a4c0 (parent) -> 5413f7d (this PR) Test differencesShow 2 test diffs2 doctest diffs were found. These are ignored, as they are noisy. Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \ test-dashboard 5413f7d39cae07b7b3809973fe201d21960a18aa --output-dir test-dashboard And then open Job duration changes
How to interpret the job duration changes?Job durations can vary a lot, based on the actual runner instance |
Finished benchmarking commit (5413f7d): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)Results (primary -4.7%, secondary -0.8%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (secondary -3.9%)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: 474.707s -> 475.31s (0.13%) |
Successful merges:
rotate_left
androtate_right
in[_]
asconst fn
items. #146841 (Stabiliserotate_left
androtate_right
in[_]
asconst fn
items.)AttributeKind::DocComment
#147699 (Clairify docs forAttributeKind::DocComment
)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup