Skip to content
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 #96075

Closed
wants to merge 21 commits into from
Closed

Conversation

RalfJung
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

anonion0 and others added 21 commits January 31, 2022 23:09
Errors from pthread_sigmask(3) were handled using cvt(), which expects a
return value of -1 on error and uses errno.
However, pthread_sigmask(3) returns 0 on success and an error number
otherwise.
Fix it by replacing cvt() with cvt_nz().
All other ABIs are left unstable for now.

cc rust-lang#64926
A more robust solution to finding where to place use suggestions was added.
The algorithm uses the AST to find the span for the suggestion so we pass this span
down to the HIR during lowering and use it.

Signed-off-by: Miguel Guarniz <[email protected]>
Since September, the toolchain has not been generating reliable DWARF
information for static variables when LTO is on. This has affected
projects in the embedded space where the use of LTO is typical. In our
case, it has kept us from bumping past the 2021-09-22 nightly toolchain
lest our debugger break. This has been a pretty dramatic regression for
people using debuggers and static variables. See rust-lang#90357 for more info
and a repro case.

This commit is a mechanical revert of
d5de680 from PR rust-lang#89041, which caused
the issue. (Note on that PR that the commit's author has requested it be
reverted.)

I have locally verified that this fixes rust-lang#90357 by restoring the
functionality of both the repro case I posted on that bug, and debugger
behavior on real programs. There do not appear to be test cases for this
in the toolchain; if I've missed them, point me at 'em and I'll update
them.
- Re-enabled basic-types-globals which has been disabled since 2018
- Updated its now-rotted assertions about GDB's output to pass
- Rewrote header comment describing some previous state of GDB behavior
  that didn't match either the checked-in assertions _or_ the current
  behavior, and so I assume has just been wrong for some time.
- Copy-pasta'd the test into a version that uses LTO to check for
  regression on rust-lang#90357, because I don't see a way to matrix the same
  test into several build configurations.
…nytm

fix error handling for pthread_sigmask(3)

Errors from `pthread_sigmask(3)` were handled using `cvt()`, which expects a return value of `-1` on error and uses `errno`.
However, `pthread_sigmask(3)` returns `0` on success and an error number otherwise.

Fix it by replacing `cvt()` with `cvt_nz()`.
…pnkfelix

Only add codegen backend to dep info if -Zbinary-dep-depinfo is used

I am currently migrating the cg_clif build system from using a binary linked to the codegen backend as rustc replacement to passing `-Zcodegen-backend` instead. Without this PR this would force cargo to rebuild the sysroot on any change to the codegen backend even if I explicitly specify that I want it to be preserved, which would make development of cg_clif a lot slower. If you still want to have changes to the codegen backend invalidate the cargo build cache you can explicitly specify `-Zbinary-dep-depinfo`.

cc ```@eddyb``` as the codegen backend was initially added to the depinfo for rust-gpu.
Parse inner attributes on inline const block

According to rust-lang#84414 (comment), inner attributes are intended to be supported *"in all containers for statements (or some subset of statements)"*.

This PR adds inner attribute parsing and pretty-printing for inline const blocks (rust-lang#76001), which contain statements just like an unsafe block or a loop body.

```rust
let _ = const {
    #![allow(...)]

    let x = ();
    x
};
```
…cement, r=pnkfelix

remove find_use_placement

A more robust solution to finding where to place use suggestions was added in rust-lang#94584.
The algorithm uses the AST to find the span for the suggestion so we pass this span
down to the HIR during lowering and use it instead of calling `find_use_placement`

Fixes rust-lang#94941
… r=pnkfelix

Stablize `const_extern_fn` for "Rust" and "C"

All other ABIs are left unstable for now.

cc rust-lang#64926
… r=pnkfelix

Revert "Work around invalid DWARF bugs for fat LTO"

Since September, the toolchain has not been generating reliable DWARF
information for static variables when LTO is on. This has affected
projects in the embedded space where the use of LTO is typical. In our
case, it has kept us from bumping past the 2021-09-22 nightly toolchain
lest our debugger break. This has been a pretty dramatic regression for
people using debuggers and static variables. See rust-lang#90357 for more info
and a repro case.

This commit is a mechanical revert of
d5de680 from PR rust-lang#89041, which caused
the issue. (Note on that PR that the commit's author has requested it be
reverted.)

I have locally verified that this fixes rust-lang#90357 by restoring the
functionality of both the repro case I posted on that bug, and debugger
behavior on real programs. There do not appear to be test cases for this
in the toolchain; if I've missed them, point me at 'em and I'll update
them.
…inline, r=oli-obk

Inline `shallow_resolve_ty` into `ShallowResolver`

addresses fixme I found in infcx
…ubilee

implement SIMD gather/scatter via vector getelementptr

Fixes rust-lang/portable-simd#271

However, I don't *really* know what I am doing here... Cc ``@workingjubilee`` ``@calebzulawski``

I didn't do anything for cranelift -- ``@bjorn3`` not sure if it's okay for that backend to temporarily break. I'm happy to cherry-pick a patch that adds cranelift support. :)
@rustbot rustbot added 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. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. rollup A PR which is a rollup labels Apr 15, 2022
@RalfJung
Copy link
Member Author

@bors r+ rollup=never p=5

@bors
Copy link
Contributor

bors commented Apr 15, 2022

📌 Commit 801d955 has been approved by RalfJung

@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 Apr 15, 2022
@bors
Copy link
Contributor

bors commented Apr 15, 2022

⌛ Testing commit 801d955 with merge 887b9aea9498ae8a23f2a699bc7dc70f33cbd7b7...

@bors
Copy link
Contributor

bors commented Apr 15, 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 Apr 15, 2022
@rust-log-analyzer
Copy link
Collaborator

The job wasm32 failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)
[RUSTC-TIMING] object test:false 6.757
[RUSTC-TIMING] gimli test:false 6.911
warning: dropping unsupported crate type `dylib` for target `wasm32-unknown-emscripten`

error: unused import: `cvt_nz`
    |
    |
282 |         use crate::sys::{self, cvt_nz, cvt_r};
    |
    |
    = note: `-D unused-imports` implied by `-D warnings`
[RUSTC-TIMING] std test:false 4.659
warning: `std` (lib) generated 1 warning
error: could not compile `std` due to previous error; 1 warning emitted
Build completed unsuccessfully in 0:13:49

@RalfJung RalfJung closed this Apr 15, 2022
@RalfJung RalfJung deleted the rollup-bet95y3 branch April 15, 2022 15:50
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. T-libs Relevant to the library team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.