-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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 7 pull requests #133787
Rollup of 7 pull requests #133787
Conversation
On nightly, we mention the trait is unstable ``` error[E0277]: the trait bound `T: Unstable` is not satisfied --> $DIR/unstable-trait-suggestion.rs:13:9 | LL | foo(t) | --- ^ the trait `Unstable` is not implemented for `T` | | | required by a bound introduced by this call | note: required by a bound in `foo` --> $DIR/unstable-trait-suggestion.rs:9:11 | LL | fn foo<T: Unstable>(_: T) {} | ^^^^^^^^ required by this bound in `foo` help: consider restricting type parameter `T` but it is an `unstable` trait | LL | pub fn demo<T: Unstable>(t: T) { | ++++++++++ ``` On stable, we don't suggest the trait at all ``` error[E0277]: the trait bound `T: Unstable` is not satisfied --> $DIR/unstable-trait-suggestion.rs:13:9 | LL | foo(t) | --- ^ the trait `Unstable` is not implemented for `T` | | | required by a bound introduced by this call | note: required by a bound in `foo` --> $DIR/unstable-trait-suggestion.rs:9:11 | LL | fn foo<T: Unstable>(_: T) {} | ^^^^^^^^ required by this bound in `foo` ```
This test will break when `Step` gets stabilized, but punt until then.
``` help: consider restricting type parameter `T` with traits `Copy` and `Trait` | LL | fn duplicate_custom<T: Copy + Trait>(t: S<T>) -> (S<T>, S<T>) { | ++++++++++++++ ``` ``` help: consider restricting type parameter `V` with trait `Copy` | LL | fn index<'a, K, V: std::marker::Copy>(map: &'a HashMap<K, V>, k: K) -> &'a V { | +++++++++++++++++++ ```
Pass in an appropriate `Option<DefId>` in more cases from hir ty lowering.
…it, r=compiler-errors Don't suggest restricting bound with unstable traits on stable and mention it's unstable on nightly On nightly, we mention the trait is unstable ``` error[E0277]: the trait bound `T: Unstable` is not satisfied --> $DIR/unstable-trait-suggestion.rs:13:9 | LL | foo(t) | --- ^ the trait `Unstable` is not implemented for `T` | | | required by a bound introduced by this call | note: required by a bound in `foo` --> $DIR/unstable-trait-suggestion.rs:9:11 | LL | fn foo<T: Unstable>(_: T) {} | ^^^^^^^^ required by this bound in `foo` help: consider restricting type parameter `T` but it is an `unstable` trait | LL | pub fn demo<T: Unstable>(t: T) { | ++++++++++ ``` On stable, we don't suggest the trait at all ``` error[E0277]: the trait bound `T: Unstable` is not satisfied --> $DIR/unstable-trait-suggestion.rs:13:9 | LL | foo(t) | --- ^ the trait `Unstable` is not implemented for `T` | | | required by a bound introduced by this call | note: required by a bound in `foo` --> $DIR/unstable-trait-suggestion.rs:9:11 | LL | fn foo<T: Unstable>(_: T) {} | ^^^^^^^^ required by this bound in `foo` ``` Fix rust-lang#133511.
…youxu Lint against Symbol::intern on a string literal Disabled in tests where this doesn't make much sense
…ve-probe-adt, r=lcnr Structurally resolve in `probe_adt` fixes rust-lang#132320 r? lcnr
…tive-if-let-rescope, r=jieyouxu Reduce false positives on some common cases from if-let-rescope lint r? ```@jieyouxu``` We would like to identify a very common case in the ecosystem in which we do not need to apply the lint suggestion for the new Edition 2024 `if let` semantics. In this patch we excluded linting from `if let`s in statements and block tail expressions. In these simple cases, new Edition 2024 drop orders are identical to those of Edition 2021 and prior. However, conservatively we should still lint for the other cases, because [this example](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=2113df5ce78f161d32a1190faf5c7469) shows that the drop order changes are very pronounced, some of which are even sensitive to runtime data.
…ingjubilee stabilize const_{size,align}_of_val FCP passed [here](rust-lang#46571 (comment)). Fixes rust-lang#46571.
… r=jieyouxu document -Zrandomize-layout in the unstable book tracking issue: rust-lang#106764 fixes rust-lang#130462
…id, r=compiler-errors Use correct `hir_id` for array const arg infers Fixes rust-lang#133771 `self.next_id()` results in the `DefId` for the const argument, created from the hack introduced by rust-lang#133468, having no `HirId` associated with it. This then results in an ICE in metadata encoding. Fixing this then results in *another* ICE where `encode_defs` was not skipping encoding `type_of` and other queries for `DefId`s when they correspond to a `ConstArgKind::Infer` node. This only reproduces with a library crate as metadata is not encoded for binaries, and apparently we had 0 tests for `generic_arg_infer` for array lengths in a library crate so this was not caught :< cc rust-lang#133589 ```@voidc``` r? ```@compiler-errors``` ```@lcnr```
@bors r+ rollup=never p=7 |
…iaskrgr Rollup of 7 pull requests Successful merges: - rust-lang#133522 (Don't suggest restricting bound with unstable traits on stable and mention it's unstable on nightly) - rust-lang#133545 (Lint against Symbol::intern on a string literal) - rust-lang#133558 (Structurally resolve in `probe_adt`) - rust-lang#133753 (Reduce false positives on some common cases from if-let-rescope lint) - rust-lang#133762 (stabilize const_{size,align}_of_val) - rust-lang#133777 (document -Zrandomize-layout in the unstable book) - rust-lang#133779 (Use correct `hir_id` for array const arg infers) r? `@ghost` `@rustbot` modify labels: rollup
The job Click to see the possible cause of the failure (guessed by this bot)
|
💔 Test failed - checks-actions |
@bors retry |
🔒 Merge conflict This pull request and the master branch diverged in a way that cannot be automatically merged. Please rebase on top of the latest master branch, and let the reviewer approve again. How do I rebase?Assuming
You may also read Git Rebasing to Resolve Conflicts by Drew Blessing for a short tutorial. Please avoid the "Resolve conflicts" button on GitHub. It uses Sometimes step 4 will complete without asking for resolution. This is usually due to difference between how Error message
|
Successful merges:
probe_adt
#133558 (Structurally resolve inprobe_adt
)hir_id
for array const arg infers #133779 (Use correcthir_id
for array const arg infers)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup