Lightnews — Scholar-powered news

Michael (compiler-errors) Goulet @errs.io · 12d

how hard is it to paste an image into an image 😭

Michael (compiler-errors) Goulet @errs.io · 15d

i dislike that one in particular. i'd be fine if it were a cheeky custom error message when the unresolved break target is `rust`, but it's implemented as a custom ICE in the compiler which is kinda annoying

1 2

Michael (compiler-errors) Goulet @errs.io · 28d

i'm noticing i am a lot saltier about being fired than i originally thought i would be

2 1 39

Michael (compiler-errors) Goulet @errs.io · 29d

not afaict, they’re ocaml as far as i can tell :)

1 5

Michael (compiler-errors) Goulet @errs.io · 29d

oh right, this all does remind me of implicits in scala. thanks for the terminology :)

2

Michael (compiler-errors) Goulet @errs.io · 29d

I will note that the Rust compiler does distinguish "instance resolution" from plain ol' "solving goals". In typeck, we only care that a where clause holds, but it doesn't necessarily know what impl a solution comes from until codegen b/c of things like opaques, where clauses that shadow impls, etc.

2

Michael (compiler-errors) Goulet @errs.io · 29d

but it is a very good point that there is some flexibility lost, though I'm not sure if there isn't a way for traits to themselves implement some kind of rank-2 "kind" and make signatures generic over *those*, for example. it wouldn't be generalizable like functors are, tho.

1

Michael (compiler-errors) Goulet @errs.io · 29d

Right, but I find that often I want my API to be meant for a single "kind" of trait. When I write `sum_values<T: Add>`, I don't want callers to provide an implementation of `Mul`, even tho it provides some binary `t -> t -> output`. So in a way it also kinda makes the API more self descriptive 🤔.

2

Michael (compiler-errors) Goulet @errs.io · 29d

Another rust could be smarter about this or have chosen a different solver strategy, but lots of reasonable code relies on this incompleteness (we've encountered a lot of cases when working on the new solver lol).

1 3

Michael (compiler-errors) Goulet @errs.io · 29d

The compiler today either just bails out with ambiguity if we don't know what to return from `.borrow()` (like we sometimes do) or be incomplete, and I guess we settled on reasonable heuristic of preferring where clauses + associated bounds which is (possibly surprisingly) often what the user wants.

1 2

Michael (compiler-errors) Goulet @errs.io · 29d

Yeah. The issue stems from the fact that there are essentially two things we're proving here that both involve inference: `O: Borrow<?0>` and `?0: PartialEq<?1>` here, and we don't really do solving at the "intersection" of two different goals even if both taken together would find a valid solution.

1 3

Michael (compiler-errors) Goulet @errs.io · 29d

the important part of (2.) is that modules (i.e. impls) themselves don't need names, since theyre uniquely identified by the `module type` being impl'd + the params, and we don't ever *need* to name them directly as a consequence of them being retrievable by this name

1 1

Michael (compiler-errors) Goulet @errs.io · 29d

by 1. treating `modules type`s nominally rather than structurally, 2. and uniquely identifying each module with a set of input parameter types (i.e. no impl overlap), we can look up a module's components by name without referencing it directly, via the `module type` + generics

1 1

Michael (compiler-errors) Goulet @errs.io · 29d

trying to make sense of ocaml modules and their conceptual relationship to rust traits... rust essentially enables "module inference" which i think is neat, especially thinking about what constraints this requires compared to ocaml where modules need to be named directly in functors

2 1 14

Michael (compiler-errors) Goulet @errs.io · 29d

Second example, yeah we prefer associated type bounds over impls so `owned.borrow()` is `&B`, which requires `B: PartialEq`.

1 2

Michael (compiler-errors) Goulet @errs.io · 29d

third example shouldn't be a mystery. `owned.borrow()` requires `O: Borrow<_>`. We prefer where clauses over the built-in reflexive `Borrow` impl, so we end up with type `&B`. That means we end up selecting the `B: PartialEq` impl in the where clause (elaborated from `B: Eq`) for the `==`.

1 2

Michael (compiler-errors) Goulet @errs.io · Sep 6

we dont have the implication that the type U in `T: Tr<Assoc = U>` implies all of the bounds of Assoc onto U, unfortunately. Doing so leads to a complexity blowup that the old solver can’t handle and the new solver would probably also choke on.

7

Reposted by Michael (compiler-errors) Goulet

Graydon Hoare @graydon-pub.bsky.social · Sep 5

I wrote about this sort of corporate mis-allocation of maintainer roles a while back and it's tragic to see such a vivid example. Let maintainers be maintainers!

graydon2.dreamwidth.org/306832.html

Michael (compiler-errors) Goulet @errs.io · Sep 5

I urge companies to take funding contributors seriously, in ways that aren’t tied to projects and goals. Being a generalist in the compiler meant that often I wasn’t working towards a roadmap, but my contributions *always* paid off in the long term extensibility of the language.

1 5 33

Michael (compiler-errors) Goulet @errs.io · Sep 5

thanks! it’s a shame i didn’t get to work on rust for longer, but i hope i made my mark and i’m glad i’m settled job-wise. hope i get to work on rust or something equivalently impactful in the future, we shall see.

1 22

Michael (compiler-errors) Goulet @errs.io · Sep 5

On the bright side, I’ll be starting a new job at Jane Street in a few months! Not sure what I’ll be doing there yet, but I’m super excited for the change of pace. If any Rust friends are in NYC, hit me up because I’ll have a lot of free time.

8 1 77

Michael (compiler-errors) Goulet @errs.io · Sep 5

I urge companies to take funding contributors seriously, in ways that aren’t tied to projects and goals. Being a generalist in the compiler meant that often I wasn’t working towards a roadmap, but my contributions *always* paid off in the long term extensibility of the language.

3 25 110

Michael (compiler-errors) Goulet @errs.io · Sep 5

That does mean I’ll be scaling back my Rust contributions over the next few months before I start my new job. Sorry to the folks who were looking forward to stuff I had in the pipeline. I really would’ve liked to deliver async fn in dyn traits or `-Zhigher-ranked-assumptions`.

1 40

Michael (compiler-errors) Goulet @errs.io · Sep 5

Unfortunately, it was not possible to snag a new job working on Rust in the way that I do today (type system/compiler frontend) especially with the freedom I have today, and I couldn't possibly be jobless for an indeterminate amount of time waiting for the right role to show up.

1 39

Michael (compiler-errors) Goulet @errs.io · Sep 5

I’m glad I got the opportunity to do amazing work on Rust over the last 3 years. It’s hard to quantify, but I hope people saw a difference due to my work on async traits/closures, the type system, diagnostics, style team, ICE fixes, internal refactors, speedups, edition 2024 etc.

1 3 61

Michael (compiler-errors) Goulet @errs.io · Sep 5

Today’s my last day at AWS working on the Rust compiler. Unfortunately, back in July I received notice that I had to choose between moving to Boston from NYC, or leaving the company due to RTO policy. I unfortunately couldn’t abandon the city I plan on being my long term home.

1 11 140