Consistently use subtyping in method resolution #126128

oli-obk · 2024-06-07T15:17:21Z

An earlier version of this PR modified how we compute variance, but the root cause was an inconsistency between the usage of eq and sub, where we assumed that the latter passing implies the former will pass.

r? @compiler-errors

rustbot · 2024-06-07T15:17:31Z

changes to the core type system

cc @compiler-errors, @lcnr

compiler/rustc_type_ir/src/lib.rs

compiler-errors · 2024-06-07T15:44:59Z

I don't personally feel comfortable about adding a new error variance. Seems really strange imo.

I think we could easily just force the error variance to Invariant rather than Bivariant, which would prevent these ICEs at risk of slightly more awkward errors, but at the benefit of not having it be its own thing that actually need to be handled in relations.

r? lcnr

compiler-errors · 2024-06-07T15:48:05Z

More thoughts:

So the underlying issue is the inconsistency we have with the xform implementation, where:

invariant xform bivariant = invariant
covariant xform bivariant = bivariant

... and the fact we're using equality during method lookup and subtyping during confirmation, leading to a mismatch in the result of those relations.

This seems like a kind of roundabout way of fixing this, since the real underlying issue is that the way we handle bivariance in the compiler is just kind of awkward.

Not to repeat myself, but I think forcing invariance would just fix things in a simpler way.

oli-obk · 2024-06-07T16:01:57Z

Not to repeat myself, but I think forcing invariance would just fix things in a simpler way.

done

compiler-errors · 2024-06-07T16:10:48Z

OK -- will review this then. Thanks for considering my feedback.

If lcnr strongly disagrees about forcing invariance, then it shouldn't be hard to do a follow-up and actually introduce the error variance later.

r? compiler-errors

compiler-errors · 2024-06-07T17:59:38Z

compiler/rustc_hir_analysis/src/check/wfcheck.rs

    }
-    res
+    Ok(variances)


Does this function ever return Err?

Unless I'm being particularly unobservant, maybe let's rename this fn to check_variances_for_type_defn_and_set_unconstrained_to_invariant

(long name but there's only a few callsites -- happy to workshop the name lol

edit: nvm I guess lol

I could return a vec of erroneous indices instead of doing the modification and the checks. Seems cleaner to separate these things

compiler-errors

some random thoughts -- pls forgive me for commenting on things that were modified subsequently in a follow-up commit lol

compiler-errors · 2024-06-07T18:00:03Z

compiler/rustc_hir_analysis/src/variance/mod.rs

-    variances
+    match crate::check::wfcheck::check_variances_for_type_defn(tcx, item_def_id, variances) {
+        Ok(variances) => variances,
+        Err(_) => tcx.arena.alloc_from_iter(variances.iter().map(|_| ty::Invariant)),


This branch is unreachable rn

compiler-errors · 2024-06-07T18:01:01Z

compiler/rustc_hir_analysis/src/check/wfcheck.rs

-            check_variances_for_type_defn(tcx, item, hir_generics);
-            res
-        }
+        hir::ItemKind::Struct(_, hir_generics) => check_type_defn(tcx, item, false)


can we use ? like:

check_type_defn()?; check_variances_for_type_defn()?;

then at the bottom we can Ok(())?

Seems to simplify control flow a bit

nvm this is irrelevant

compiler-errors · 2024-06-07T18:01:34Z

compiler/rustc_hir_analysis/src/check/wfcheck.rs

    }
-    res
+    Ok(variances)


edit: nvm I guess lol

compiler-errors · 2024-06-07T18:04:00Z

compiler/rustc_hir_analysis/src/check/wfcheck.rs

-                if field.ty(tcx, identity_args).references_error() {
-                    return;
-                }
+                field.ty(tcx, identity_args).error_reported()?;


I wonder if we should just use error_reported to delay the error message below but don't early-return (using emit_unless). I kinda feel bad that we're setting all of the substs to bivariant even if they are constrained otherwise (e.g. to covariance) somewhere else in the definition.

Yea, these early aborts were preexisting. I didn't want to touch them in the previously-big PR (I'm assuming they got added to avoid ICEs), but now it's reasonable to investigate.

lcnr · 2024-06-10T08:11:58Z

More thoughts:

So the underlying issue is the inconsistency we have with the xform implementation, where:
* invariant xform bivariant = invariant

* covariant xform bivariant = bivariant
... and the fact we're using equality during method lookup and subtyping during confirmation, leading to a mismatch in the result of those relations.

We get subtyping to succeed and equate to fail and that causes an ICE because we expect "subtype implies equal"? The underlying issue is just that, isn't it? We have types which are subtypes of each other but not equal. Apart from variance this is also the case with the leak check. This can't currently trigger as we just put the nested obligations in the FnCtxt without trying them, even in the new solver, but if we were to eagerly compute nested obligations, the following test would ICE https://rust.godbolt.org/z/KxGeqevaW.

I also don't see how this PR fixes the underlying issue with bivariance:

trait Proj {
    type Assoc;
}
impl<T> Proj for T {
    type Assoc = T;
}

struct Fail<T: Proj<Assoc = U>, U>(T);

impl Fail<i32, i32> {
    const C: () = ();
}

fn main() {
    Fail::<i32, u32>::C
    // expected: WF error
    // actual: ICE
}

oli-obk · 2024-06-10T10:25:20Z

We get subtyping to succeed and equate to fail and that causes an ICE because we expect "subtype implies equal"? The underlying issue is just that, isn't it?

yes, but I did not want to touch that behaviour, because I really can't tell the implications. Almost nothing should be affected, because we already generate fresh inference vars during method resolution, so all we're doing is constraining inference vars that have no other constraints.

I did the change (see latest force push), and the only affected test is never type fallback, which checks with my analysis above.

tests/ui/associated-consts/wrong-projection-self-ty-on-invalid-type2.rs

lcnr · 2024-06-10T11:17:32Z

tests/ui/coercion/coerce-issue-49593-box-never.rs

-    //[nofallback]~^ ERROR trait bound `(): std::error::Error` is not satisfied
+    // Subtyping during method resolution will generate new inference vars and
+    // subtype them. Thus fallback will not fall back to `!`, but `()` instead.
+    Box::<_ /* ! */>::new(x)


why this change?

Instead of merging the two infer vars, we now create a subtyping relation for them, so they aren't the same. Never type fallback will still fall back to ! for the one type var, but the other type var which is a subtype, will only fall back to (). I haven't debugged this deeply, since never type fallback is cursed and debugging it will probably yield no new information beyond all the edge cases that already are know for never type fallback.

oh lel, you didn't change the UI test, you just reformatted it

lcnr · 2024-06-10T11:34:03Z

yes, but I did not want to touch that behaviour, because I really can't tell the implications.

I think non-method calls should use eq instead of sub everywhere 🤔 it seems surprising that Type::<Subtype>::CONST works? though i'd like @compiler-errors input on that

oli-obk · 2024-06-10T13:02:33Z

#122317 (fully) switched from eq to subtyping

lcnr · 2024-06-10T13:24:58Z

oh well, that's ugly 🤔

struct B<T>(T);

impl B<fn(&'static ())> {
    fn method(self) {
        println!("hey");
    }
}

fn foo(x: B<for<'a> fn(&'a ())>) {
    x.method();
}

fn main() {
    B::<for<'a> fn(&'a ())>::method(B(|&()| ()));
}

i expected us to only use subtyping when looking up the self type, not when using a path 🤔 that's kinda meh. But yeah, I guess sub is fine here, opening an issue as I would like to try and change that

…iaskrgr Rollup of 8 pull requests Successful merges: - rust-lang#125722 (Indicate in `non_local_defs` lint that the macro needs to change) - rust-lang#125829 (rustc_span: Add conveniences for working with span formats) - rust-lang#126128 (Consistently use subtyping in method resolution) - rust-lang#126192 (Various Redox OS fixes and add i686 Redox OS target) - rust-lang#126352 (ci: Update centos:7 to use vault repos) - rust-lang#126354 (Use `Variance` glob imported variants everywhere) - rust-lang#126469 (MIR Shl/Shr: the offset can be computed with rem_euclid) - rust-lang#126472 (build `libcxx-version` only when it doesn't exist) r? `@ghost` `@rustbot` modify labels: rollup

matthiaskrgr · 2024-06-14T16:45:43Z

@bors r-
#126480 (comment)

…subtyping

oli-obk · 2024-06-17T10:58:11Z

@bors r=lcnr

bors · 2024-06-17T10:58:13Z

📌 Commit 3e6e6b1 has been approved by lcnr

It is now in the queue for this repository.

bors · 2024-06-17T12:08:20Z

⌛ Testing commit 3e6e6b1 with merge 9b584a6...

Consistently use subtyping in method resolution fixes rust-lang#126062 An earlier version of this PR modified how we compute variance, but the root cause was an inconsistency between the usage of `eq` and `sub`, where we assumed that the latter passing implies the former will pass. r? `@compiler-errors`

bors · 2024-06-17T14:21:03Z

☀️ Test successful - checks-actions
Approved by: lcnr
Pushing 9b584a6 to master...

rust-timer · 2024-06-17T16:44:46Z

Finished benchmarking commit (9b584a6): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

This benchmark run did not return any relevant results for this metric.

Cycles

Results (primary 5.0%)

This 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.

	mean	range	count
Regressions ❌ (primary)	5.0%	[5.0%, 5.0%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	5.0%	[5.0%, 5.0%]	1

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 669.445s -> 670.422s (0.15%)
Artifact size: 320.51 MiB -> 319.89 MiB (-0.19%)

…=<try> Relate receiver invariantly in method probe for `Mode::Path` Reverts rust-lang#126128 Fixes the part of rust-lang#122317 which always used subtyping instead of eq Fixes rust-lang#126227 (TODO: test) WIP: description r? lcnr

This MR contains the following updates: | Package | Update | Change | |---|---|---| | [rust](https://github.com/rust-lang/rust) | minor | `1.80.1` -> `1.81.0` | MR created with the help of [el-capitano/tools/renovate-bot](https://gitlab.com/el-capitano/tools/renovate-bot). **Proposed changes to behavior should be submitted there as MRs.** --- ### Release Notes <details> <summary>rust-lang/rust (rust)</summary> ### [`v1.81.0`](https://github.com/rust-lang/rust/blob/HEAD/RELEASES.md#Version-1810-2024-09-05) [Compare Source](rust-lang/rust@1.80.1...1.81.0) \========================== <a id="1.81.0-Language"></a> ## Language - [Abort on uncaught panics in `extern "C"` functions.](rust-lang/rust#116088) - [Fix ambiguous cases of multiple `&` in elided self lifetimes.](rust-lang/rust#117967) - [Stabilize `#[expect]` for lints (RFC 2383),](rust-lang/rust#120924) like `#[allow]` with a warning if the lint is *not* fulfilled. - [Change method resolution to constrain hidden types instead of rejecting method candidates.](rust-lang/rust#123962) - [Bump `elided_lifetimes_in_associated_constant` to deny.](rust-lang/rust#124211) - [`offset_from`: always allow pointers to point to the same address.](rust-lang/rust#124921) - [Allow constraining opaque types during subtyping in the trait system.](rust-lang/rust#125447) - [Allow constraining opaque types during various unsizing casts.](rust-lang/rust#125610) - [Deny keyword lifetimes pre-expansion.](rust-lang/rust#126762) <a id="1.81.0-Compiler"></a> ## Compiler - [Make casts of pointers to trait objects stricter.](rust-lang/rust#120248) - [Check alias args for well-formedness even if they have escaping bound vars.](rust-lang/rust#123737) - [Deprecate no-op codegen option `-Cinline-threshold=...`.](rust-lang/rust#124712) - [Re-implement a type-size based limit.](rust-lang/rust#125507) - [Properly account for alignment in `transmute` size checks.](rust-lang/rust#125740) - [Remove the `box_pointers` lint.](rust-lang/rust#126018) - [Ensure the interpreter checks bool/char for validity when they are used in a cast.](rust-lang/rust#126265) - [Improve coverage instrumentation for functions containing nested items.](rust-lang/rust#127199) - Target changes: - [Add Tier 3 `no_std` Xtensa targets:](rust-lang/rust#125141) `xtensa-esp32-none-elf`, `xtensa-esp32s2-none-elf`, `xtensa-esp32s3-none-elf` - [Add Tier 3 `std` Xtensa targets:](rust-lang/rust#126380) `xtensa-esp32-espidf`, `xtensa-esp32s2-espidf`, `xtensa-esp32s3-espidf` - [Add Tier 3 i686 Redox OS target:](rust-lang/rust#126192) `i686-unknown-redox` - [Promote `arm64ec-pc-windows-msvc` to Tier 2.](rust-lang/rust#126039) - [Promote `loongarch64-unknown-linux-musl` to Tier 2 with host tools.](rust-lang/rust#126298) - [Enable full tools and profiler for LoongArch Linux targets.](rust-lang/rust#127078) - [Unconditionally warn on usage of `wasm32-wasi`.](rust-lang/rust#126662) (see compatibility note below) - Refer to Rust's \[platform support page]\[platform-support-doc] for more information on Rust's tiered platform support. <a id="1.81.0-Libraries"></a> ## Libraries - [Split core's `PanicInfo` and std's `PanicInfo`.](rust-lang/rust#115974) (see compatibility note below) - [Generalize `{Rc,Arc}::make_mut()` to unsized types.](rust-lang/rust#116113) - [Replace sort implementations with stable `driftsort` and unstable `ipnsort`.](rust-lang/rust#124032) All `slice::sort*` and `slice::select_nth*` methods are expected to see significant performance improvements. See the [research project](https://github.com/Voultapher/sort-research-rs) for more details. - [Document behavior of `create_dir_all` with respect to empty paths.](rust-lang/rust#125112) - [Fix interleaved output in the default panic hook when multiple threads panic simultaneously.](rust-lang/rust#127397) <a id="1.81.0-Stabilized-APIs"></a> ## Stabilized APIs - [`core::error`](https://doc.rust-lang.org/stable/core/error/index.html) - [`hint::assert_unchecked`](https://doc.rust-lang.org/stable/core/hint/fn.assert_unchecked.html) - [`fs::exists`](https://doc.rust-lang.org/stable/std/fs/fn.exists.html) - [`AtomicBool::fetch_not`](https://doc.rust-lang.org/stable/core/sync/atomic/struct.AtomicBool.html#method.fetch_not) - [`Duration::abs_diff`](https://doc.rust-lang.org/stable/core/time/struct.Duration.html#method.abs_diff) - [`IoSlice::advance`](https://doc.rust-lang.org/stable/std/io/struct.IoSlice.html#method.advance) - [`IoSlice::advance_slices`](https://doc.rust-lang.org/stable/std/io/struct.IoSlice.html#method.advance_slices) - [`IoSliceMut::advance`](https://doc.rust-lang.org/stable/std/io/struct.IoSliceMut.html#method.advance) - [`IoSliceMut::advance_slices`](https://doc.rust-lang.org/stable/std/io/struct.IoSliceMut.html#method.advance_slices) - [`PanicHookInfo`](https://doc.rust-lang.org/stable/std/panic/struct.PanicHookInfo.html) - [`PanicInfo::message`](https://doc.rust-lang.org/stable/core/panic/struct.PanicInfo.html#method.message) - [`PanicMessage`](https://doc.rust-lang.org/stable/core/panic/struct.PanicMessage.html) These APIs are now stable in const contexts: - [`char::from_u32_unchecked`](https://doc.rust-lang.org/stable/core/char/fn.from_u32\_unchecked.html) (function) - [`char::from_u32_unchecked`](https://doc.rust-lang.org/stable/core/primitive.char.html#method.from_u32\_unchecked) (method) - [`CStr::count_bytes`](https://doc.rust-lang.org/stable/core/ffi/c_str/struct.CStr.html#method.count_bytes) - [`CStr::from_ptr`](https://doc.rust-lang.org/stable/core/ffi/c_str/struct.CStr.html#method.from_ptr) <a id="1.81.0-Cargo"></a> ## Cargo - [Generated `.cargo_vcs_info.json` is always included, even when `--allow-dirty` is passed.](rust-lang/cargo#13960) - [Disallow `package.license-file` and `package.readme` pointing to non-existent files during packaging.](rust-lang/cargo#13921) - [Disallow passing `--release`/`--debug` flag along with the `--profile` flag.](rust-lang/cargo#13971) - [Remove `lib.plugin` key support in `Cargo.toml`. Rust plugin support has been deprecated for four years and was removed in 1.75.0.](rust-lang/cargo#13902) <a id="1.81.0-Compatibility-Notes"></a> ## Compatibility Notes - Usage of the `wasm32-wasi` target will now issue a compiler warning and request users switch to the `wasm32-wasip1` target instead. Both targets are the same, `wasm32-wasi` is only being renamed, and this [change to the WASI target](https://blog.rust-lang.org/2024/04/09/updates-to-rusts-wasi-targets.html) is being done to enable removing `wasm32-wasi` in January 2025. - We have renamed `std::panic::PanicInfo` to `std::panic::PanicHookInfo`. The old name will continue to work as an alias, but will result in a deprecation warning starting in Rust 1.82.0. `core::panic::PanicInfo` will remain unchanged, however, as this is now a *different type*. The reason is that these types have different roles: `std::panic::PanicHookInfo` is the argument to the [panic hook](https://doc.rust-lang.org/stable/std/panic/fn.set_hook.html) in std context (where panics can have an arbitrary payload), while `core::panic::PanicInfo` is the argument to the [`#[panic_handler]`](https://doc.rust-lang.org/nomicon/panic-handler.html) in no_std context (where panics always carry a formatted *message*). Separating these types allows us to add more useful methods to these types, such as `std::panic::PanicHookInfo::payload_as_str()` and `core::panic::PanicInfo::message()`. - The new sort implementations may panic if a type's implementation of [`Ord`](https://doc.rust-lang.org/std/cmp/trait.Ord.html) (or the given comparison function) does not implement a [total order](https://en.wikipedia.org/wiki/Total_order) as the trait requires. `Ord`'s supertraits (`PartialOrd`, `Eq`, and `PartialEq`) must also be consistent. The previous implementations would not "notice" any problem, but the new implementations have a good chance of detecting inconsistencies, throwing a panic rather than returning knowingly unsorted data. - [In very rare cases, a change in the internal evaluation order of the trait solver may result in new fatal overflow errors.](rust-lang/rust#126128) <a id="1.81.0-Internal-Changes"></a> ## Internal Changes These changes do not affect any public interfaces of Rust, but they represent significant improvements to the performance or internals of rustc and related tools. - [Add a Rust-for Linux `auto` CI job to check kernel builds.](rust-lang/rust#125209) </details> --- ### Configuration 📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined). 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever MR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this MR and you won't be reminded about this update again. --- - [ ] If you want to rebase/retry this MR, check this box --- This MR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate).

… r=lcnr Relate receiver invariantly in method probe for `Mode::Path` Effectively reverts part of rust-lang#126128 Fixes rust-lang#126227 This PR changes method probing to use equality for fully path-based method lookup, and subtyping for receiver `.` method lookup. r? lcnr

…=lcnr Relate receiver invariantly in method probe for `Mode::Path` Effectively reverts part of rust-lang#126128 Fixes rust-lang#126227 This PR changes method probing to use equality for fully path-based method lookup, and subtyping for receiver `.` method lookup. r? lcnr

rustbot assigned compiler-errors Jun 7, 2024

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 Jun 7, 2024

oli-obk force-pushed the method_ice branch from 4d5f434 to 026183d Compare June 7, 2024 15:32

This comment has been minimized.

Sign in to view

compiler-errors reviewed Jun 7, 2024

View reviewed changes

compiler/rustc_type_ir/src/lib.rs Outdated Show resolved Hide resolved

rustbot assigned lcnr and unassigned compiler-errors Jun 7, 2024

oli-obk force-pushed the method_ice branch from 026183d to b80c1ae Compare June 7, 2024 15:46

oli-obk force-pushed the method_ice branch from b80c1ae to 8a6b4d5 Compare June 7, 2024 16:01

rustbot assigned compiler-errors and unassigned lcnr Jun 7, 2024

oli-obk changed the title ~~Add an error variance and use it to silence follow-up errors~~ set erroneous bivariant generic params to invariant to silence follow-up errors Jun 7, 2024

compiler-errors reviewed Jun 7, 2024

View reviewed changes

oli-obk force-pushed the method_ice branch from 8a6b4d5 to 4aa34df Compare June 10, 2024 10:24

lcnr reviewed Jun 10, 2024

View reviewed changes

tests/ui/associated-consts/wrong-projection-self-ty-on-invalid-type2.rs Outdated Show resolved Hide resolved

lcnr reviewed Jun 10, 2024

View reviewed changes

lcnr mentioned this pull request Jun 10, 2024

inherent method selection uses subtyping even when using paths #126227

Closed

oli-obk force-pushed the method_ice branch from 4aa34df to a18d67f Compare June 13, 2024 09:27

bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jun 14, 2024

oli-obk force-pushed the method_ice branch from 956370b to 9802e15 Compare June 17, 2024 09:28

This comment has been minimized.

Sign in to view

oli-obk force-pushed the method_ice branch from 9802e15 to 14b6223 Compare June 17, 2024 09:54

This comment has been minimized.

Sign in to view

oli-obk added 2 commits June 17, 2024 10:57

Use subtyping instead of equality, since method resolution also uses …

94f5495

…subtyping

Remove windows-specific copy of test

3e6e6b1

oli-obk force-pushed the method_ice branch from 14b6223 to 3e6e6b1 Compare June 17, 2024 10:58

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-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jun 17, 2024

GuillaumeGomez mentioned this pull request Jun 17, 2024

Rollup of 3 pull requests #126590

Closed

bors added the merged-by-bors This PR was explicitly merged by bors. label Jun 17, 2024

bors merged commit 9b584a6 into rust-lang:master Jun 17, 2024
7 checks passed

rustbot added this to the 1.81.0 milestone Jun 17, 2024

oli-obk deleted the method_ice branch June 17, 2024 16:49

This was referenced Aug 9, 2024

regression: overflow evaluating the requirement #128887

Open

Relate receiver invariantly in method probe for Mode::Path #129073

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Consistently use subtyping in method resolution #126128

Consistently use subtyping in method resolution #126128

oli-obk commented Jun 7, 2024 •

edited

Loading

rustbot commented Jun 7, 2024

This comment has been minimized.

compiler-errors commented Jun 7, 2024 •

edited

Loading

compiler-errors commented Jun 7, 2024 •

edited

Loading

oli-obk commented Jun 7, 2024

compiler-errors commented Jun 7, 2024

compiler-errors Jun 7, 2024

compiler-errors Jun 7, 2024

oli-obk Jun 7, 2024

compiler-errors left a comment

compiler-errors Jun 7, 2024

compiler-errors Jun 7, 2024

compiler-errors Jun 7, 2024

compiler-errors Jun 7, 2024

compiler-errors Jun 7, 2024

compiler-errors Jun 7, 2024

oli-obk Jun 7, 2024

lcnr commented Jun 10, 2024 •

edited

Loading

oli-obk commented Jun 10, 2024

lcnr Jun 10, 2024

oli-obk Jun 13, 2024

lcnr Jun 14, 2024

lcnr commented Jun 10, 2024

oli-obk commented Jun 10, 2024 •

edited

Loading

lcnr commented Jun 10, 2024

matthiaskrgr commented Jun 14, 2024

This comment has been minimized.

This comment has been minimized.

oli-obk commented Jun 17, 2024

bors commented Jun 17, 2024

bors commented Jun 17, 2024

bors commented Jun 17, 2024

rust-timer commented Jun 17, 2024

Consistently use subtyping in method resolution #126128

Consistently use subtyping in method resolution #126128

Conversation

oli-obk commented Jun 7, 2024 • edited Loading

rustbot commented Jun 7, 2024

This comment has been minimized.

compiler-errors commented Jun 7, 2024 • edited Loading

compiler-errors commented Jun 7, 2024 • edited Loading

oli-obk commented Jun 7, 2024

compiler-errors commented Jun 7, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

compiler-errors left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lcnr commented Jun 10, 2024 • edited Loading

oli-obk commented Jun 10, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lcnr commented Jun 10, 2024

oli-obk commented Jun 10, 2024 • edited Loading

lcnr commented Jun 10, 2024

matthiaskrgr commented Jun 14, 2024

This comment has been minimized.

This comment has been minimized.

oli-obk commented Jun 17, 2024

bors commented Jun 17, 2024

bors commented Jun 17, 2024

bors commented Jun 17, 2024

rust-timer commented Jun 17, 2024

Overall result: no relevant changes - no action needed

oli-obk commented Jun 7, 2024 •

edited

Loading

compiler-errors commented Jun 7, 2024 •

edited

Loading

compiler-errors commented Jun 7, 2024 •

edited

Loading

lcnr commented Jun 10, 2024 •

edited

Loading

oli-obk commented Jun 10, 2024 •

edited

Loading