Michael Goulet comments

Results 300 comments of


                                            Michael Goulet

Generic trait with generic supertrait bound by associated type can't be used in trait bound with associated type

The diagnostic needs to be suppressed in this case, but also I don't know why this doesn't work but it's probably due to normalization and substitution somewhere happening in the...

Generic trait with generic supertrait bound by associated type can't be used in trait bound with associated type

Ugh this is a really strange param env normalization bug.

Trait methods with bounds on `Self` are shown on types that do not fulfill those bounds

For the record I was working on this, sorry for not claiming this... Anyways, let me know if you don't get around to this, and I'll pick it back up...

Trait methods with bounds on `Self` are shown on types that do not fulfill those bounds

Thank you @chenyukang. Sorry for the mistake, and I am excited for you to get involved more in the compiler :) @rustbot claim

Trait methods with bounds on `Self` are shown on types that do not fulfill those bounds

This is a dupe of #80481

Trait methods with bounds on `Self` are shown on types that do not fulfill those bounds

Uh, sorry, actually not a dupe. That's impl level, this is method level. I think there were legitimate concerns with hiding whole impls in that other issue. Reopening this, andf...

const fns cannot have fn pointer arguments that take mutable references, even if they aren't called

hm, @rust-lang/wg-const-eval does anyone know if we're being too aggressive by denying `fn(&mut T)` in const fns? I think this is a side-effect of using `Ty::walk` when checking for mut...

const fns cannot have fn pointer arguments that take mutable references, even if they aren't called

I was actually thinking of whether we want to make this _more_ restrictive (seems more correct) by checking ADT fields -- but walking into the ADT fields actually causes core...

const fns cannot have fn pointer arguments that take mutable references, even if they aren't called

I was thinking about that yesterday. It should be easy to deny just the derefs in MIR right? I can get that implemented if so.

ICE when using non-lifetimes in `for<>`

> I'm not sure what the policy is though, an ICE on stable (even though not occurring on nightly) is still an ICE? There's nothing more to do except for...