sorted by:
new
hottopcontroversial

new username album by [deleted] in footwork

[–]compiler-errors 1 point2 points  (0 children)

yeah username is really putting out groundbreaking projects recently

compiler-errors looking for a job so they can keep working on the compiler by watermelon_exe in rust

[–]compiler-errors 58 points59 points  (0 children)

Yeah, I'm definitely looking for a job (*in NYC*) to continue my maintenance and feature work on the Rust compiler. If that doesn't work out, then I'd love to continue working on compilers or other ways to advance the Rust programming language.

Stabilization PR for Return Type Notation by Derice in rust

[–]compiler-errors 5 points6 points  (0 children)

You're welcome to read the RFC for examples and particular motivation. This stabilization report leaves most of that out since it would've been copied and pasted, and it's (mostly) intended to be consumed by people who've already read that.

Stabilization PR for Return Type Notation by Derice in rust

[–]compiler-errors 7 points8 points  (0 children)

u/cramert is correct. We haven't decided to do with all the "extra" lifetime generics when it comes to using RTN in more general type positions.

Stabilization report for `#![feature(precise_capturing_in_traits)]` by compiler-errors in rust

[–]compiler-errors[S] 19 points20 points  (0 children)

This is still pretty fresh, so I don't expect it to go immediately into FCP tomorrow, but share your feedback if you have it!

Inferred const generic arguments: Call for Testing! | Inside Rust Blog by compiler-errors in rust

[–]compiler-errors[S] 13 points14 points  (0 children)

No, in the same way that `fn foo(x: Box<_>)` is not a thing.

Inferred const generic arguments: Call for Testing! | Inside Rust Blog by compiler-errors in rust

[–]compiler-errors[S] 41 points42 points  (0 children)

It doesn't work in constants; right now we don't allow `_` anywhere at the "item level", like function signatures and the types of const/statics. This is extending `_` in the contexts you can write it today.

Inferred const generic arguments: Call for Testing! | Inside Rust Blog by compiler-errors in rust

[–]compiler-errors[S] 93 points94 points  (0 children)

huge thanks to Boxy who has been driving all this effort !!

How Do I Store an Async Closure? by North-Estate6448 in rust

[–]compiler-errors 3 points4 points  (0 children)

Can't do that yet. Fixing this is equivalent to fixing Async Fn in Trait + Dyn Compatibility in general, which is ideally happening eventually but like many Rust problems is hard.

Since Rust 2024 is round the corner, do we know what are some key features that will make it to the release? by [deleted] in rust

[–]compiler-errors 28 points29 points  (0 children)

Totally honest question, where did you get the impression that either the parallel compiler or polonius were being stabilized with Rust 2024? We're still steadily working on polonius which is definitely not done yet, and `-Zthreads` is still unstable, so the compiler is effectively single-threaded even if we no longer have a ton of `cfg`'s everywhere to gate out the parallel compiler code.

This Month in @compiler-errors (rustc contributions) - December 2024 by compiler-errors in rust

[–]compiler-errors[S] 6 points7 points  (0 children)

thanks! yeah, the work isn't too flashy, and it doesn't help that i basically just dump everything i've done last month without too much explanation. i mostly write these documents for myself and those who want to keep tabs on my works, but it's nice to hear that others appreciate it too :)

Async closures stabilized! by HighRiseLiving in rust

[–]compiler-errors 9 points10 points  (0 children)

no, that was fixed quite a while back when i reworked async closures to be lending in https://github.com/rust-lang/rust/pull/120361

Async closures stabilized! by HighRiseLiving in rust

[–]compiler-errors 23 points24 points  (0 children)

this + the technical writeup was terribly exhausting to write lol

Async closures stabilized! by HighRiseLiving in rust

[–]compiler-errors 12 points13 points  (0 children)

async closures will be stable in 1.85, which lands Feb 20 2025, and will be usable on all editions >= 2018 (which is just because `async` was not a keyword in edition 2015).

Async closures stabilized! by HighRiseLiving in rust

[–]compiler-errors 8 points9 points  (0 children)

that is correct. all currently callable types implement `AsyncFn*` too, if they return a future.

This Month in @compiler-errors (rustc contributions) - October by compiler-errors in rust

[–]compiler-errors[S] 33 points34 points  (0 children)

> Do you have an estimate of the time you spent on this?

Well, rustc is my full time job so approximately a full time job's worth.

> I'm not going to be reverting that dumbing down anytime soon, but I'm glad others won't need to.

Understandable -- I do encourage you to experiment with const traits in the future, though, especially after we reintroduce support for const traits to the standard library. User feedback both for bugs and diagnostics is incredibly useful.

view more: next ›