-
Notifications
You must be signed in to change notification settings - Fork 52
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
Resolve the biggest blockers to Linux building on stable Rust #116
Comments
This issue is intended for status updates only. For general questions or comments, please contact the owner(s) directly. |
Key developments:
Next steps
|
Key developments:
Next steps:
|
Brief updates from today's meeting (minutes):
|
Summary of meeting from Nov 20, prepared by @traviscross: we went through a number of items proposed as 2025H1 project goals. The lang ones all seemed reasonable and achievable project goals. (We didn't get through all the non-lang items, so there's more to cover in the next meeting.) Wesley mentioned that @adetaylor may not be available to continue pursuing arbitrary self types in 2025, so he's been prioritizing reviews on those to get things in this year, and that we may have to find someone to push this forward if it goes beyond that. Alice mentioned that CoercePointee may be blocked on arbitrary self types, but wanted to think more about how fundamental that blockage is. There was a lot of discussion about how to rebuild core in a stable way. Wesley mentioned an interesting thing, which is that the Cargo team would like rustc to support passing a compressed crate file to rustc, and that if we could do that, then we could distribute a core.crate via rustup. Kind of interesting. There are also some items that the RfL folks want to get into unstable by Rust 1.85 as they may be stuck on that version for a long time. The main one for us is some way to relax the orphan rule. I suggested they file and nominate an ask for a lang experiment here. |
November updates:
|
FCP on rust-lang/rfcs#3716 has been proposed. |
Summary from today's meeting: we've completed all language items but arbitrary self types, and the heavy lifting there is done. We have diagnostic work to do and then we want to get some feedback but we expect to be able to move to stabilization soon. Arbitrary self typesThe bulk of the impl work has landed, crater run showed no fallout. The only known outstanding work is improving diagnostics. After that the next step will be stabilization. The main blocker is having some folks to play around with it and ensuring that it meets all the use cases it was meant to meet. Derive smart pointer
|
Summary
Stabilize unstable features required by Rust for Linux project including
offset_of!
supportTasks and status
Overall program management (@nikomatsakis, @joshtriplett)
Arbitrary self types v2 (@adetaylor) -- tracked in Tracking issue for RFC 3519:
arbitrary_self_types
rust#44874Derive smart pointer (@Darksonn)
author RFCderive(SmartPtr)
rust#129104SmartPointer
toCoercePointee
rust#131284SmartPointer
toCoercePointee
rust#131284 (compiler )asm_goto
(@Darksonn)implementationasm
goto should default to safe rust#132078) (lang ) -- currently in FCPExtended
offset_of
syntax (@dingxiangfei2009)RFL on Rust CI(@Kobzol)implementationPointers to static in constants (@nikomatsakis) -- Tracking Issue for const_refs_to_static rust#119618
const_refs_to_static
rust#128183)const_refs_to_static
rust#129759const
expression can borrow static items reference#1610Compiler flags like fixed-x18
The text was updated successfully, but these errors were encountered: