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 10 pull requests #122031

Closed
wants to merge 28 commits into from

Conversation

matthiaskrgr
Copy link
Member

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

ajwock and others added 28 commits February 18, 2024 19:55
With rust 1.75 the absolute build path is embedding into '.rustc' section and which causes reproducibility issues. Detailed issue is here.
rust-lang#120825 (comment)

With this change the 'absolute path' changed back to '/rust/$hash' format.
Unnamed union fields with enums are checked for, but if `find_field`
causes an ICE then the compiler won't get to that point.

Signed-off-by: David Wood <[email protected]>
…types_defined_by`

Instead, when we're collecting opaques for associated items, we choose the right collection mode depending on whether we're collecting for an associated item of a trait impl or not.
…r=cuviper

std support for wasm32 panic=unwind

Tracking issue: rust-lang#118168

This adds std support for `-Cpanic=unwind` on wasm, and with it slightly more fleshed out rustc support. Now, the stable default is still panic=abort without exception-handling, but if you `-Zbuild-std` with `RUSTFLAGS=-Cpanic=unwind`, you get wasm exception-handling try/catch blocks in the binary:

```rust
#[no_mangle]
pub fn foo_bar(x: bool) -> *mut u8 {
    let s = Box::<str>::from("hello");
    maybe_panic(x);
    Box::into_raw(s).cast()
}

#[inline(never)]
#[no_mangle]
fn maybe_panic(x: bool) {
    if x {
        panic!("AAAAA");
    }
}
```
```wat
;; snip...
(try $label$5
 (do
  (call $maybe_panic
   (local.get $0)
  )
  (br $label$1)
 )
 (catch_all
  (global.set $__stack_pointer
   (local.get $1)
  )
  (call $__rust_dealloc
   (local.get $2)
   (i32.const 5)
   (i32.const 1)
  )
  (rethrow $label$5)
 )
)
;; snip...
```
…li-obk

Hint user to update nightly on ICEs produced from outdated nightly

This is a conservative best-effort approach to detect a potentially outdated nightly; it will fallback to the regular ICE-reporting if any of the following cases are true:
- Channel is not nightly
- Version information is not available
- Version date is not parseable as a YYYY-MM-DD or is missing
- System time is at least 36 hours ahead of the user's nightly release datetime.
- Any internal features are used.

Note that I'm not sure how to make a test for this: I tested this manually by `CFG_VER_DATE="2020-02-02" ./x build library --stage 1`, and also changing the channel detection in `rustc_driver_impl` from `Some("nightly")` to `Some("nightly" | "dev")`, and then running `rustc +stage1 test.rs -Ztreat-err-as-bug=1` with a non-existent `test.rs`.

<img width="1145" alt="Screenshot 2024-02-27 at 01 12 28" src="https://github.com/rust-lang/rust/assets/39484203/eff6af2e-4b19-4a70-af57-cd739ecf0e84">

Closes rust-lang#118832.
Removing absolute path in proc-macro

With rust 1.75 the absolute build path name is embedding into proc-macro (.rustc section) and which causes reproducibility issues.
Detailed issue description is here - rust-lang#120825 (comment)

With this change the 'absolute path' changed back to '/rust/$hash' format as in earlier revisions.
…nkov

hir_analysis: enums return `None` in `find_field`

Fixes rust-lang#121757.

Unnamed union fields with enums are checked for, but if `find_field` causes an ICE then the compiler won't get to that point.
…th, r=bjorn3

Fix duplicated path in the "not found dylib" error

While working on the gcc backend, I couldn't figure out why I had this error:

```
error: couldn't load codegen backend /checkout/compiler/rustc_codegen_gcc/target/release/librustc_codegen_gcc.so/checkout/compiler/rustc_codegen_gcc/target/release/librustc_codegen_gcc.so: cannot open shared object file: No such file or directory
```

As you can see, the path is duplicated for some reason. After investigating a bit more, I realized that `libloading::Error::LoadLibraryExW` starts with the path of the not found dylib, making it appear twice in our error afterward (because we do render it like this: `{path}{err}`, and since the `err` starts with the path...).

Thanks to ```@bjorn3``` for linking me to rust-lang#121392. :)
…_by_queries, r=compiler-errors

Merge impl_trait_in_assoc_types_defined_by query back into `opaque_types_defined_by`

Instead, when we're collecting opaques for associated items, we choose the right collection mode depending on whether we're collecting for an associated item of a trait impl or not.

r? `@compiler-errors`

follow up to rust-lang#121838
will_wake tests fail on Miri and that is expected

Follow-up to rust-lang#121622
r? `@cuviper` `@dtolnay`
only set noalias on Box with the global allocator

As discovered in rust-lang/miri#3341, `noalias` and custom allocators don't go well together.

rustc can now check whether a Box uses the global allocator. This replaces the previous ad-hoc and rather unprincipled check for a zero-sized allocator.

This is the rustc part of fixing that; Miri will also need a patch.
@rustbot rustbot added 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. labels Mar 5, 2024
@rustbot rustbot added T-libs Relevant to the library team, which will review and decide on the PR/issue. rollup A PR which is a rollup labels Mar 5, 2024
@matthiaskrgr
Copy link
Member Author

@bors r+ rollup=never p=10

@bors
Copy link
Contributor

bors commented Mar 5, 2024

📌 Commit 8834019 has been approved by matthiaskrgr

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 5, 2024
@bors
Copy link
Contributor

bors commented Mar 5, 2024

⌛ Testing commit 8834019 with merge 9caa535...

bors added a commit to rust-lang-ci/rust that referenced this pull request Mar 5, 2024
…iaskrgr

Rollup of 10 pull requests

Successful merges:

 - rust-lang#121280 (Implement MaybeUninit::fill{,_with,_from})
 - rust-lang#121438 (std support for wasm32 panic=unwind)
 - rust-lang#121658 (Hint user to update nightly on ICEs produced from outdated nightly)
 - rust-lang#121959 (Removing absolute path in proc-macro)
 - rust-lang#121961 (add test for rust-lang#78894 rust-lang#71450)
 - rust-lang#121975 (hir_analysis: enums return `None` in `find_field`)
 - rust-lang#121978 (Fix duplicated path in the "not found dylib" error)
 - rust-lang#121991 (Merge impl_trait_in_assoc_types_defined_by query back into `opaque_types_defined_by`)
 - rust-lang#122016 (will_wake tests fail on Miri and that is expected)
 - rust-lang#122018 (only set noalias on Box with the global allocator)

r? `@ghost`
`@rustbot` modify labels: rollup
@rust-log-analyzer
Copy link
Collaborator

The job test-various failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)
[RUSTC-TIMING] corebenches test:true 0.043
error[E0412]: cannot find type `Rc` in this scope
   --> library/core/tests/mem.rs:340:9
    |
340 |     rc: Rc<()>,
    |
help: consider importing this struct
    |
1   + use std::rc::Rc;
1   + use std::rc::Rc;
    |

error[E0433]: failed to resolve: use of undeclared type `Rc`
   --> library/core/tests/mem.rs:345:12
    |
345 |         if Rc::strong_count(&self.rc) >= self.limit {
    |            ^^ use of undeclared type `Rc`
help: consider importing this struct
    |
1   + use std::rc::Rc;
    |

@bors
Copy link
Contributor

bors commented Mar 5, 2024

💔 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 5, 2024
@matthiaskrgr matthiaskrgr deleted the rollup-mp1ii7n branch March 16, 2024 18:19
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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.