Rollup of 4 iffy pull requests #91455
Conversation
... if they use arbitrary enum discriminant. Code like
```rust
enum Enum {
Foo = 1,
Bar(),
Baz{}
}
```
seems to be unintentionally allowed so we couldn't disallow them now,
but we could disallow them if arbitrary enum discriminant is used before
1.56 hits stable.
Disallow non-c-like but "fieldless" ADTs from being casted to integer if they use arbitrary enum discriminant
Code like
```rust
#[repr(u8)]
enum Enum {
Foo /* = 0 */,
Bar(),
Baz{}
}
let x = Enum::Bar() as u8;
```
seems to be unintentionally allowed so we couldn't disallow them now ~~, but we could disallow them if arbitrary enum discriminant is used before 1.56 hits stable~~ (stabilization was reverted).
Related: rust-lang#88621
`@rustbot` label +T-lang
…nkov Issue 90702 fix: Stop treating some crate loading failures as fatal errors Surface mulitple `extern crate` resolution errors at a time. This is achieved by creating a dummy crate, instead of aborting directly after the resolution error. The `ExternCrateError` has been added to allow propagating the resolution error from `rustc_metadata` crate to the `rustc_resolve` with a minimal public surface. The `import_extern_crate` function is a block that was factored out from `build_reduced_graph_for_item` for better organization. The only added functionality made to it where the added error handling in the `process_extern_crate` call. The remaining bits in this function are the same as before. Resolves rust-lang#90702 r? `@petrochenkov`
…roalbini Bump stage0 compiler r? `@pietroalbini` (or anyone else)
…nkov Enable svh tests on msvc These tests were ignored for msvc in rust-lang#30778 because of additional notes that were being added for some reason. I'm fairly confident this has been fixed in the intervening years so lets try re-enabling these tests. Fixes rust-lang#31306
|
@bors r+ rollup=never p=4 |
|
📌 Commit 822a058 has been approved by |
bors
added
the
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
|
Finished benchmarking commit (e5038e2): comparison url. Summary: This change led to very large relevant mixed results 🤷 in compiler performance.
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 |
|
Mmh, I would assume we benchmark the stage2 compiler anyway so bootstrap bump should not have a big effect, so probably one of the first two..? |
|
@matthiaskrgr for the future, it's usually good to not group iffy pull requests into the same PR. It's better to group an iffy PR with other clearly non-performance sensitive PRs so that if a perf regression happens, you can go with the hypothesis that the iffy PR caused the regression. It'll likely be too difficult to figure out the cause of the regression given how small the regression actually is (0.8% is the largest regression in a non-noisy test case). @rustbot label: +perf-regression-triaged |
rustbot
added
the
perf-regression-triaged
|
@rylev isn't that was rollup=never is for? |
Successful merges:
Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup