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 9 pull requests #122040

Closed
wants to merge 25 commits into from

Conversation

matthiaskrgr
Copy link
Member

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

jieyouxu and others added 20 commits February 27, 2024 01:13
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 <david@davidtw.co>
Signed-off-by: David Wood <david@davidtw.co>
…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=pnkfelix

Limit the number of names and values in check-cfg diagnostics

The Rust for Linux [feedback](rust-lang#82450 (comment)) to the check-cfg Call for Testing, revealed a weakness in the check-cfg. They are unbounded and in the case RfL they have ~20k cfgs and having them printed (even once) is unbearable.

This PR limits it to 35 (28 rustc well known + `feature` + `docsrs` + 5 custom) which feels like a good middle ground for regular users (i.e. Cargo users).

When it goes over that limit print the N first with " and X more".

`@rustbot` label +F-check-cfg
…r=pnkfelix

errors: share `SilentEmitter` between rustc and rustfmt

Fixes rust-lang/rustfmt#6082.

Shares the `SilentEmitter` between rustc and rustfmt, and gives it a fallback bundle (since it can emit diagnostics in some contexts).
…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.
only compare ambiguity item that have hard error

Fixes rust-lang#121760

An easy fix, r? `@petrochenkov`
…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
@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. 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=9

@bors
Copy link
Contributor

bors commented Mar 5, 2024

📌 Commit 4614ab7 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
reitermarkus and others added 4 commits March 9, 2024 00:45
…, r=oli-obk

Move generic `NonZero` `rustc_layout_scalar_valid_range_start` attribute to inner type.

Tracking issue: rust-lang#120257

r? `@dtolnay`
@matthiaskrgr matthiaskrgr deleted the rollup-kgb8mfh 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-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. 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.