-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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 #120722
Rollup of 9 pull requests #120722
Conversation
Co-authored-by: Urgau <3616612+Urgau@users.noreply.github.com>
When encountering ```rust fn f<T>(a: T, b: T) -> std::cmp::Ordering { a.cmp(&b) //~ ERROR E0599 } ``` output ``` error[E0599]: no method named `cmp` found for type parameter `T` in the current scope --> $DIR/method-on-unbounded-type-param.rs:2:7 | LL | fn f<T>(a: T, b: T) -> std::cmp::Ordering { | - method `cmp` not found for this type parameter LL | a.cmp(&b) | ^^^ method cannot be called on `T` due to unsatisfied trait bounds | = help: items from traits can only be used if the type parameter is bounded by the trait help: the following traits define an item `cmp`, perhaps you need to restrict type parameter `T` with one of them: | LL | fn f<T: Ord>(a: T, b: T) -> std::cmp::Ordering { | +++++ LL | fn f<T: Iterator>(a: T, b: T) -> std::cmp::Ordering { | ++++++++++ ``` Fix rust-lang#120186.
When a method not found on a type parameter could have been provided by any of multiple traits, suggest each trait individually, instead of a single suggestion to restrict the type parameter with *all* of them. Before: ``` error[E0599]: the method `cmp` exists for reference `&T`, but its trait bounds were not satisfied --> $DIR/method-on-unbounded-type-param.rs:5:10 | LL | (&a).cmp(&b) | ^^^ method cannot be called on `&T` due to unsatisfied trait bounds | = note: the following trait bounds were not satisfied: `T: Ord` which is required by `&T: Ord` `&T: Iterator` which is required by `&mut &T: Iterator` `T: Iterator` which is required by `&mut T: Iterator` help: consider restricting the type parameters to satisfy the trait bounds | LL | fn g<T>(a: T, b: T) -> std::cmp::Ordering where T: Iterator, T: Ord { | +++++++++++++++++++++++++ ``` After: ``` error[E0599]: the method `cmp` exists for reference `&T`, but its trait bounds were not satisfied --> $DIR/method-on-unbounded-type-param.rs:5:10 | LL | (&a).cmp(&b) | ^^^ method cannot be called on `&T` due to unsatisfied trait bounds | = note: the following trait bounds were not satisfied: `T: Ord` which is required by `&T: Ord` `&T: Iterator` which is required by `&mut &T: Iterator` `T: Iterator` which is required by `&mut T: Iterator` = help: items from traits can only be used if the type parameter is bounded by the trait help: the following traits define an item `cmp`, perhaps you need to restrict type parameter `T` with one of them: | LL | fn g<T: Ord>(a: T, b: T) -> std::cmp::Ordering { | +++++ LL | fn g<T: Iterator>(a: T, b: T) -> std::cmp::Ordering { | ++++++++++ ``` Fix rust-lang#108428.
and bless a test I missed
…e, r=compiler-errors Improve 'generic param from outer item' error for `Self` and inside `static`/`const` items Fixes rust-lang#109596 Fixes rust-lang#119936
pattern_analysis: use a plain `Vec` in `DeconstructedPat` The use of an arena-allocated slice in `DeconstructedPat` dates to when we needed the arena anyway for lifetime reasons. Now that we don't, I'm thinking that if `thir::Pat` can use plain old `Vec`s, maybe so can I. r? ```@ghost```
…param, r=nnethercote Account for unbounded type param receiver in suggestions When encountering ```rust fn f<T>(a: T, b: T) -> std::cmp::Ordering { a.cmp(&b) //~ ERROR E0599 } ``` output ``` error[E0599]: no method named `cmp` found for type parameter `T` in the current scope --> $DIR/method-on-unbounded-type-param.rs:2:7 | LL | fn f<T>(a: T, b: T) -> std::cmp::Ordering { | - method `cmp` not found for this type parameter LL | a.cmp(&b) | ^^^ method cannot be called on `T` due to unsatisfied trait bounds | = help: items from traits can only be used if the type parameter is bounded by the trait help: the following traits define an item `cmp`, perhaps you need to restrict type parameter `T` with one of them: | LL | fn f<T: Ord>(a: T, b: T) -> std::cmp::Ordering { | +++++ LL | fn f<T: Iterator>(a: T, b: T) -> std::cmp::Ordering { | ++++++++++ ``` Fix rust-lang#120186.
…, r=petrochenkov update indirect structural match lints to match RFC and to show up for dependencies This is a large step towards implementing rust-lang/rfcs#3535. We currently have five lints related to "the structural match situation": - nontrivial_structural_match - indirect_structural_match - pointer_structural_match - const_patterns_without_partial_eq - illegal_floating_point_literal_pattern This PR concerns the first 3 of them. (The 4th already is set up to show for dependencies, and the 5th is removed by rust-lang#116284.) nontrivial_structural_match is being removed as per the RFC; the other two are enabled to show up in dependencies. Fixes rust-lang#73448 by removing the affected analysis.
…ame, r=Urgau,Nilstrieb Suggest name value cfg when only value is used for check-cfg Fixes rust-lang#120427 r? `````````````@Nilstrieb`````````````
…, r=compiler-errors Remove `ffi_returns_twice` feature The [tracking issue](rust-lang#58314) and [RFC](rust-lang/rfcs#2633) have been closed for a couple of years. There is also an attribute gate in R-A which should be removed if this lands.
Account for non-overlapping unmet trait bounds in suggestion When a method not found on a type parameter could have been provided by any of multiple traits, suggest each trait individually, instead of a single suggestion to restrict the type parameter with *all* of them. Before: ``` error[E0599]: the method `cmp` exists for reference `&T`, but its trait bounds were not satisfied --> $DIR/method-on-unbounded-type-param.rs:5:10 | LL | (&a).cmp(&b) | ^^^ method cannot be called on `&T` due to unsatisfied trait bounds | = note: the following trait bounds were not satisfied: `T: Ord` which is required by `&T: Ord` `&T: Iterator` which is required by `&mut &T: Iterator` `T: Iterator` which is required by `&mut T: Iterator` help: consider restricting the type parameters to satisfy the trait bounds | LL | fn g<T>(a: T, b: T) -> std::cmp::Ordering where T: Iterator, T: Ord { | +++++++++++++++++++++++++ ``` After: ``` error[E0599]: the method `cmp` exists for reference `&T`, but its trait bounds were not satisfied --> $DIR/method-on-unbounded-type-param.rs:5:10 | LL | (&a).cmp(&b) | ^^^ method cannot be called on `&T` due to unsatisfied trait bounds | = note: the following trait bounds were not satisfied: `T: Ord` which is required by `&T: Ord` `&T: Iterator` which is required by `&mut &T: Iterator` `T: Iterator` which is required by `&mut T: Iterator` = help: items from traits can only be used if the type parameter is bounded by the trait help: the following traits define an item `cmp`, perhaps you need to restrict type parameter `T` with one of them: | LL | fn g<T: Ord>(a: T, b: T) -> std::cmp::Ordering { | +++++ LL | fn g<T: Iterator>(a: T, b: T) -> std::cmp::Ordering { | ++++++++++ ``` Fix rust-lang#108428. Follow up to rust-lang#120396, only last commit is relevant.
…for-nll, r=lcnr Normalize type outlives obligations in NLL for new solver Normalize the type outlives assumptions and obligations in MIR borrowck. This should fix any of the lazy-norm-related MIR borrowck problems. Also some cleanups from last PR: 1. Normalize obligations in a loop in lexical region resolution 2. Use `deeply_normalize_with_skipped_universes` in lexical resolution since we may have, e.g. `for<'a> Alias<'a>: 'b`. r? lcnr
…=nnethercote Don't expect early-bound region to be local when reporting errors in RPITIT well-formedness The implicit lifetime in the example code gets replaced with `ReError`, which fails a `sub_regions` check in the lexical region solver. Error reporting ends up calling `is_suitable_region` on an early bound region in the *trait* definition. This causes an ICE because we `expect_local()`. This is kind of a bad explanation, but this code just makes diagnostics reporting a bit more gracefully fallible. If the reviewer wants a thorough investigation of exactly where we get this region outlives obligation, I can write one up. Doesn't really seem worth it, though, imo. Fixes rust-lang#120638 Fixes rust-lang#120648
@bors r+ rollup=never p=9 |
☀️ Test successful - checks-actions |
📌 Perf builds for each rolled up PR:
previous master: 256b6fb19a In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
Finished benchmarking commit (586893c): comparison URL. Overall result: ✅ improvements - no action needed@rustbot label: -perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)This benchmark run did not return any relevant results for this metric. CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Bootstrap: 662.479s -> 663.003s (0.08%) |
Successful merges:
Self
and insidestatic
/const
items #119939 (Improve 'generic param from outer item' error forSelf
and insidestatic
/const
items)Vec
inDeconstructedPat
#120331 (pattern_analysis: use a plainVec
inDeconstructedPat
)ffi_returns_twice
feature #120502 (Removeffi_returns_twice
feature)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup