Skip to content

Rollup of 4 pull requests #95205

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

Closed
wants to merge 10 commits into from
Closed

Conversation

Dylan-DPC
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

workingjubilee and others added 10 commits March 17, 2022 16:19
Arm's FEAT_FP and Feat_AdvSIMD describe the same thing on AArch64:
The Neon unit, which handles both floating point and SIMD instructions.
Moreover, a configuration for AArch64 must include both or neither.
Arm says "entirely proprietary" toolchains may omit floating point:
https://developer.arm.com/documentation/102374/0101/Data-processing---floating-point
In the Programmer's Guide for Armv8-A, Arm says AArch64 can have
both FP and Neon or neither in custom implementations:
https://developer.arm.com/documentation/den0024/a/AArch64-Floating-point-and-NEON

In "Bare metal boot code for Armv8-A", enabling Neon and FP
is just disabling the same trap flag:
https://developer.arm.com/documentation/dai0527/a

In an unlikely future where "Neon and FP" become unrelated,
we can add "[+-]fp" as its own feature flag.
Until then, we can simplify programming with Rust on AArch64 by
folding both into "[+-]neon", which is valid as it supersets both.

"[+-]neon" is retained for niche uses such as firmware, kernels,
"I just hate floats", and so on.
Fold aarch64 feature +fp into +neon

Arm's FEAT_FP and Feat_AdvSIMD describe the same thing on AArch64:
The Neon unit, which handles both floating point and SIMD instructions.
Moreover, a configuration for AArch64 must include both or neither.
Arm says "entirely proprietary" toolchains may omit floating point:
https://developer.arm.com/documentation/102374/0101/Data-processing---floating-point
In the Programmer's Guide for Armv8-A, Arm says AArch64 can have
both FP and Neon or neither in custom implementations:
https://developer.arm.com/documentation/den0024/a/AArch64-Floating-point-and-NEON

In "Bare metal boot code for Armv8-A", enabling Neon and FP
is just disabling the same trap flag:
https://developer.arm.com/documentation/dai0527/a

In an unlikely future where "Neon and FP" become unrelated,
we can add "[+-]fp" as its own feature flag.
Until then, we can simplify programming with Rust on AArch64 by
folding both into "[+-]neon", which is valid as it supersets both.

"[+-]neon" is retained for niche uses such as firmware, kernels,
"I just hate floats", and so on.

I am... pretty sure no one is relying on this.

An argument could be made that, as we are not an "entirely proprietary" toolchain, we should not support AArch64 without floats at all. I think that's a bit excessive. However, I want to recognize the intent: programming for AArch64 should be simplified where possible. For x86-64, programmers regularly set up illegal feature configurations because it's hard to understand them, see rust-lang#89586. And per the above notes, plus the discussion in rust-lang#86941, there should be no real use cases for leaving these features split: the two should in fact always go together.

Fixes rust-lang#95002.
Fixes rust-lang#95122.
Move std::sys::{mutex, condvar, rwlock} to std::sys::locks.

This cleans up the the std::sys modules a bit by putting the locks in a single module called `locks` rather than spread over the three modules `mutex`, `condvar`, and `rwlock`. This makes it easier to organise lock implementations, which helps with rust-lang#93740.
rename LocalState::Uninitialized to Unallocated

This is to avoid confusion with `Uninit` as in `ScalarMaybeUninit`, which is very different.

r? `@oli-obk`
…en-parsing-generic-arg, r=oli-obk

Cancel a not emitted error after parsing const generic args

closes rust-lang#95163
@rustbot rustbot added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. rollup A PR which is a rollup labels Mar 22, 2022
@Dylan-DPC
Copy link
Member Author

@bors r+ rollup=never p=5

@bors
Copy link
Collaborator

bors commented Mar 22, 2022

📌 Commit c7e1757 has been approved by Dylan-DPC

@bors bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Mar 22, 2022
@bors
Copy link
Collaborator

bors commented Mar 22, 2022

⌛ Testing commit c7e1757 with merge 2cf31768d2fe34e0be9ad2206c162ac6ad20b0dc...

@rust-log-analyzer
Copy link
Collaborator

The job aarch64-gnu failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

---- [ui] ui/asm/aarch64/bad-reg.rs stdout ----
diff of stderr:

+ '+fp' is not a recognized feature for this target (ignoring feature)
1 error: invalid register class `foo`: unknown register class
3    |


The actual stderr differed from the expected stderr.
The actual stderr differed from the expected stderr.
Actual stderr saved to /checkout/obj/build/aarch64-unknown-linux-gnu/test/ui/asm/aarch64/bad-reg/bad-reg.stderr
To only update this specific test, also pass `--test-args asm/aarch64/bad-reg.rs`

error: 1 errors occurred comparing output.
status: exit status: 1
status: exit status: 1
command: "/checkout/obj/build/aarch64-unknown-linux-gnu/stage2/bin/rustc" "/checkout/src/test/ui/asm/aarch64/bad-reg.rs" "-Zthreads=1" "--target=aarch64-unknown-linux-gnu" "--error-format" "json" "--json" "future-incompat" "-Ccodegen-units=1" "-Zui-testing" "-Zdeduplicate-diagnostics=no" "--emit" "metadata" "-C" "prefer-dynamic" "--out-dir" "/checkout/obj/build/aarch64-unknown-linux-gnu/test/ui/asm/aarch64/bad-reg" "-A" "unused" "-Crpath" "-O" "-Cdebuginfo=0" "-Lnative=/checkout/obj/build/aarch64-unknown-linux-gnu/native/rust-test-helpers" "-C" "target-feature=+fp" "-L" "/checkout/obj/build/aarch64-unknown-linux-gnu/test/ui/asm/aarch64/bad-reg/auxiliary"
stdout: none
--- stderr -------------------------------
'+fp' is not a recognized feature for this target (ignoring feature)
error: invalid register class `foo`: unknown register class
   |
   |
LL |         asm!("{}", in(foo) foo);


error: invalid register `foo`: unknown register
   |
   |
LL |         asm!("", in("foo") foo);

error: invalid asm template modifier for this register class
  --> /checkout/src/test/ui/asm/aarch64/bad-reg.rs:18:15
   |
   |
LL |         asm!("{:z}", in(reg) foo);
   |               ^^^^   ----------- argument
   |               template modifier
   |
   |
   = note: the `reg` register class supports the following template modifiers: `w`, `x`
error: invalid asm template modifier for this register class
  --> /checkout/src/test/ui/asm/aarch64/bad-reg.rs:20:15
   |
   |
LL |         asm!("{:r}", in(vreg) foo);
   |               ^^^^   ------------ argument
   |               template modifier
   |
   |
   = note: the `vreg` register class supports the following template modifiers: `b`, `h`, `s`, `d`, `q`, `v`
error: invalid asm template modifier for this register class
  --> /checkout/src/test/ui/asm/aarch64/bad-reg.rs:22:15
   |
   |
LL |         asm!("{:r}", in(vreg_low16) foo);
   |               ^^^^   ------------------ argument
   |               template modifier
   |
   |
   = note: the `vreg_low16` register class supports the following template modifiers: `b`, `h`, `s`, `d`, `q`, `v`

error: asm template modifiers are not allowed for `const` arguments
   |
   |
LL |         asm!("{:a}", const 0);
   |               ^^^^   ------- argument
   |               template modifier


error: asm template modifiers are not allowed for `sym` arguments
   |
   |
LL |         asm!("{:a}", sym main);
   |               ^^^^   -------- argument
   |               template modifier


error: invalid register `x29`: the frame pointer cannot be used as an operand for inline asm
   |
   |
LL |         asm!("", in("x29") foo);


error: invalid register `sp`: the stack pointer cannot be used as an operand for inline asm
   |
   |
LL |         asm!("", in("sp") foo);


error: invalid register `xzr`: the zero register cannot be used as an operand for inline asm
   |
   |
LL |         asm!("", in("xzr") foo);


error: invalid register `x19`: x19 is used internally by LLVM and cannot be used as an operand for inline asm
   |
   |
LL |         asm!("", in("x19") foo);


error: register class `preg` can only be used as a clobber, not as an input or output
   |
   |
LL |         asm!("", in("p0") foo);


error: register class `preg` can only be used as a clobber, not as an input or output
   |
   |
LL |         asm!("{}", in(preg) foo);


error: register class `preg` can only be used as a clobber, not as an input or output
   |
   |
LL |         asm!("{}", out(preg) _);


error: register `x0` conflicts with register `x0`
   |
   |
LL |         asm!("", in("x0") foo, in("w0") bar);
   |                  ------------  ^^^^^^^^^^^^ register `x0`
   |                  register `x0`


error: register `x0` conflicts with register `x0`
   |
   |
LL |         asm!("", in("x0") foo, out("x0") bar);
   |                  ------------  ^^^^^^^^^^^^^ register `x0`
   |                  register `x0`
   |
   |
help: use `lateout` instead of `out` to avoid conflict
   |
   |
LL |         asm!("", in("x0") foo, out("x0") bar);


error: register `v0` conflicts with register `v0`
   |
   |
LL |         asm!("", in("v0") foo, in("q0") bar);
   |                  ------------  ^^^^^^^^^^^^ register `v0`
   |                  register `v0`


error: register `v0` conflicts with register `v0`
   |
   |
LL |         asm!("", in("v0") foo, out("q0") bar);
   |                  ------------  ^^^^^^^^^^^^^ register `v0`
   |                  register `v0`
   |
   |
help: use `lateout` instead of `out` to avoid conflict
   |
   |
LL |         asm!("", in("v0") foo, out("q0") bar);

error: aborting due to 18 previous errors
------------------------------------------

@bors
Copy link
Collaborator

bors commented Mar 22, 2022

💔 Test failed - checks-actions

@bors 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 22, 2022
@Dylan-DPC Dylan-DPC closed this Mar 22, 2022
@Dylan-DPC Dylan-DPC deleted the rollup-809orpa branch March 22, 2022 15:05
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-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants