Compiling Rust with GCC: an update

Posted Sep 12, 2022 17:10 UTC (Mon) by moltonel (subscriber, #45207)
In reply to: Compiling Rust with GCC: an update by mathstuf
Parent article: Compiling Rust with GCC: an update

> You do have CI set up for your MSRV, right?

*I* do, but I'm pretty sure that's not universally the case. The point is not that the issue can be tested for, but that there is a new issue to be aware of. Also, I'm willing to bet that some developers will only setup their CI with gccrs, for philosophical reasons or to reduce resource usage.

Gccrs could probably prevent the issue by adopting rustc's #[feature(...)] system, but feature names are a bit implementation-specific, it's not clear how to make that work well with multiple implementations.

> unlikely to declare "supports Rust 1.X" without supporting every (compiler feature) that X implies

That was my understanding so far. But the implementation of const generics before they reached the 1.49 milestone casts a doubt. How will gccrs describe its current feature set ? "1.49 plus const generics as of 1.60 plus features X and Y" ? "1.60 except feature Z" ? Users will simplify that in their head to a single version number, and possibly write an optimistic MSRV to Cargo.toml.

To be fair, these feature differences are surmountable (maybe sites like caniuse.rs could start tracking gccrs and cg_gcc), and it's normal for gccrs to want to release features without exactly following rustc's release history, but as a user I yearn for a simple "gccrs version X matches the features of rustc version Y".

to post comments

Compiling Rust with GCC: an update

Posted Sep 12, 2022 18:38 UTC (Mon) by mathstuf (subscriber, #69389) [Link] (1 responses)

> How will gccrs describe its current feature set ?

If I were the gccrs developers, I'd probably describe it as "1.49 with additional implemented features". Or, more succinctly, "see our issue tracking for specifics because we are still under heavy development".

> Users will simplify that in their head to a single version number, and possibly write an optimistic MSRV to Cargo.toml.

Users will do awful things. What do you suppose anyone do about it?

> it's normal for gccrs to want to release features without exactly following rustc's release history,

Yeah, railroading any implementation to limitations such as "you cannot make stdlib function X const before you implement $complicated_compiler_feature that took rustc developer 5 years to do" is…really strict and basically saying "none may pass"-style goalposts along this road.

> but as a user I yearn for a simple "gccrs version X matches the features of rustc version Y".

I sympathize, but I've also been in this field long enough to know that such things are usually hiding Lovecraftian contortions to make such a facade.

Compiling Rust with GCC: an update

Posted Sep 12, 2022 22:41 UTC (Mon) by moltonel (subscriber, #45207) [Link]

Fair enough, you're right, some amount of messiness is unavoidable. But keeping the feature diff small is a good ideal to aim for.

Compiling Rust with GCC: an update

Posted Sep 12, 2022 22:24 UTC (Mon) by himi (subscriber, #340) [Link]

>That was my understanding so far. But the implementation of const generics before they reached the 1.49 milestone casts a doubt. How will gccrs describe its current feature set ? "1.49 plus const generics as of 1.60 plus features X and Y" ? "1.60 except feature Z" ? Users will simplify that in their head to a single version number, and possibly write an optimistic MSRV to Cargo.toml.

Don't they just mean that during development they're targeting 1.49 for the moment, and in order to be able to support testing with the kernel (and satisfying the preference from a lot of kernel devs for having multiple compilers) they're also trying to get a move on with some more advanced features the kernel project needs? As in, they haven't set their supported version in stone, they're just using some of them as goal posts, with the kernel stuff as an additional goal post.

Presumably before they announce they're production ready for kernel builds they'll reach something a lot closer to feature parity. And presumably they'll only announce "supports version 1.foo" when they have full feature parity with version 1.foo, for exactly the reasons you've noted.

They're still in fairly early development - maybe wait until they're closer to actual release candidates before dinging them for how they're talking about feature/version support . . .

Compiling Rust with GCC: an update

Posted Sep 13, 2022 11:19 UTC (Tue) by milesrout (subscriber, #126894) [Link] (2 responses)

What's the point of multiple implementations if it's insisted that they all operate completely in lockstep, a few versions behind rustc? What's the point of multiple implementations if the "rustc" version is considered the same thing as the Rust version?

The best thing about having a separate Rust implementation would be that long-needed features could be implemented and used that have been languishing in RFCs for years being bikeshedded to death. How long did it take for const generics to be added? And they're still highly limited. Where are generic associated types? Tracking issue open for FIVE YEARS. Where are DST coercions? The DST coercion tracking issue has been open for SEVEN YEARS, almost as long as Rust has existed, and they're going nowhere.

Compiling Rust with GCC: an update

Posted Oct 1, 2022 12:44 UTC (Sat) by sammythesnake (guest, #17693) [Link] (1 responses)

That sounds like a very risky prospect to me.

If those bikeshedded features do eventually escape the shed and appear in rust (as defined by rustic or by some future official spec) they may not do so unchanged from whatever variant was implemented in whatever codebase jumped the gun. Then what we have is two implementations that are incompatible and codebases designed for each one.

At the very least, it would be necessary to have some way to indicate (analogously with editions?) which version of which features are implemented (e.g. rust 1.55 + shiny-new-feature-1-from-draft-spec-NNNN-x.yy.zzz + shiny-new-feature-2-from-draft-spec-MMMM-a.bb.ccc + ...) that code could indicate it's coded for.

To be able to compile such code, rustc (or any third implementation) would also have to provide compatible support for these incompatible variants. Variants that they explicitly declined to implement pending conclusion of bikeshedding.

I suppose they could be handled similarly to unstable features, though.

If the additions were limited to adding selected features from a future edition (e.g. rust 1.55 + feature-AAAA-from-rust-1.56) then you could reasonably hope that the more involved edition-plus-modifiers thing might at least be *forward* compatible, but still horribly convoluted and developers would likely much prefer to keep the number of modifiers specified to a minimum by simply upping the edition they specify at the first opportunity.

In a worse scenario, though, the features caught in bikeshed limbo might be decisively NACKed leaving two permanently diverged forks of the language. That can't possibly be a good thing.

Perhaps lessons can be learned from "browser feature detection" in various JavaScript libraries which has been a thing for quite some time. Is it reliably non-nightmarish...?

Compiling Rust with GCC: an update

Posted Oct 1, 2022 14:05 UTC (Sat) by Wol (subscriber, #4433) [Link]

I think anything like that is promptly going to fall foul of different people running different rustc.

If there are two major compilers, stuff will be NACK'd if it doesn't run on both. And even if it's bikeshedded over, the "editions" stuff will make sure it's okay.

(And from the efforts the rust people are going to for linux, and also given Linus' very pragmatic not purist attitude, stuff that linux wants is not likely to suffer too much bikeshedding. Even if it does (quite likely) end up as "this only exists in unsafe code".)

Cheers,
Wol