Why is Rustc not enough?
So an eventual gccrust would allow using rust on a much wider set of platforms, which is nice.
Do we have proof backing up this claim?
For example, a list of new previously-unrepported bugs that have been uncovered by the GCC Rust re-implementation of the Rust language frontend?
Every single time I had to do this, I opened a PR to the Rust reference with the fix. :shrug:
> That should never happen.
Sure, and the way this gets fixed is with documentation. GCC frontends have this same problem. I've had to read the GCC C++ frontend source code a million times already to figure out if it was standard compliant. When it wasn't, I sent a patch fixing it, instead of.... starting rewriting a new frontend from scratch.
Compared with GCC, the Rust frontend source code was almost every single time infinitely better documented. Many internal modules are actually intended to be read as documentation, and I do read the rendered compiler API docs every now and then when looking for something. The quality of GCC docs was... not great.
> C++ has only benefited from having multiple compilers.
C++ starting point was very different than Rust's.
> If you're afraid of fragmentation or Rust dying as a result of this, I can assure you that historically, the exact opposite takes place.
I'm not afraid, just curious about what value is in here.
I don't see why anyone would use GCC Rust, instead of the GCC backend, for anything. Most real-world Rust projects use 100s of crates.io dependencies. All real-word Rust projects I use, use nightly, and crates from crates.io that work on nightly. No idea how GCC Rust could achieve "daily" parity with Rust for anything practical. What's the strategy here?
Why would that not be the case? crates.io is just a code repository like any other. You don't need crates.io to write/use Rust code, and crates.io has no specific requirement for a certain compiler.
It just so happens that currently only the main implementation of Rust language (rustc) can compile all of crates.io repository, but this could change in the future.
this is frequently taken as axiomatic but there's no actual support for it in reality. there are plenty of healthy single-implementation languages (go, rust, scala, erlang) and plenty of unhealthy multi-implementation languages (c, d, sql, javascript) to go alongside the healthy/multi (python, ruby) and unhealthy/single (php, i guess, i don't care about this quadrant very much)
Can you point us to the documentation bugs that you filled upstream for each of these issues ?
I think it would make sense to tag them with "GCC Rust" or so, to be able to study them as a whole.
I'm not sure what this tells you about Rust. By definition, it is conforming with itself.
That said, you are still right that it is a thing that the gcc-rust developers will need to keep up with.
>> By definition, it is conforming with itself.
If the implementation is the specification, then how do you know what is a bug and what is a feature?
Reviewers / authors / community determine whether its a bug in the compiler or in the spec or both, or not.
- How do you know that's something is a compiler bug? Compiler writers typically know.
- How do you know that's something is a spec bug? All Rust spec changes go through the RFC process. If the proposal doesn't mention the issue, then its probably a bug. There are also many people maintaining the Rust spec. These people usually know.
If nobody knows, you submit an RFC, explaining why you think is a bug. The community can then reading, and the appropriate teams can decide, and if it is merged, then it is a bug.
The fix lands at some point, and the fixed Language / standard library / implementation becomes Rust 1.X.Y.
Done.
---
This is much simpler than in C++, where if you think you found a bug... you could open it in clang or gcc, but if its a spec bug, then that's the wrong place, and it might get closed with "not a bug". Ok so you need to open it in the spec, which you can do, but without you being an ISO member (and paying) there is little on your hand to push this forward.... Anyways supposed this is fixed in the spec, you then re-open it in the implementation you cared about. This might be fixed, or not. Probably not, because it would make this implementation incompatible with another existing one (e.g. clang incompatible with GCC), and that other one could say "fixing this breaks too much code, we won't fix it", so.... now you need to coordinate a bugfix deployment across multiple implementations.
Even if you manage that, most fixes get backported, so that means these things introduce breaking changes in, e.g., old C++ standard versions, breaking old code that assumed those to be "stable", etc. And how these fixes are backported differs from compiler to compiler, so now you get a new set of incompatibilities.
Some compilers like clang, have flags to configure which fixes get applied and which aren't (e.g. -fabi-compat=...) so that the user can choose which versions with which specification patches of which other compilers the generated code should be compatible with.
How many bugs does the C++ spec have?
Thousands: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html
What happens if you screw your C++ compatibility settings when mixing code from different toolchains (e.g. a library compiled with clang on linux with a binary compiled with gcc or viceveersa) ? Undefined behavior.
Avoiding the discussions and "forking the frontend to do a different thing" because "omgz rustc docs are bad and rustc devs can't be trusted" doesn't seem too valuable to me (but I guess to some people).
1. Keep up with rustc language development 2. How do we handle inconsistencies in behaviour
For inconsistencies, we have stated in our FAQ that if GCC rust does not behave the same as rustc. Then it is a bug with GCC rust. So it is not fruitful for us to raise issues with rustc until we can compile and run the test suite, even though I have some edge cases worth exploring.
Keeping up with the language is a more difficult one, and it depends on your outlook. From my perspective, I think it would be ideal if Rust would version the language. For example, every new release of rustc might include:
- New unstable lang features. - new language editions (like the upcoming 2021) - Stdlib updates and stabilisations. - Features like incremental compilation. - Bug fixes. - Dependencies updates like LLVM.
This is a lot of stuff that might change, and it's only the rust compiler version that gets updated for all of this work. I can see why this is the case, and it has benefits, but I am not sure rust editions are enough.
Currently, there is little to no benefit to picking a version of Rust to target. When new features are stabilised like const generics, this means state of the art in developing robust rust crates changes overnight, pushing the whole ecosystem onto the latest version of rustc. This is neat in some ways, but I am unsure how this will play out in the long run for Rust.
For me, an alternative front-end from GCC means backing from the GCC toolchain and a way to backport Rust to older versions of GCC. This also means that custom arch vendors whose only toolchains are custom GCC/binutils can also benefit from Rust as it will be part of the upstream project.
We can also explore things like language versioning with the gcc toolchain. Or explore some of the standardization efforts which I do think is important.
Other than that, big projects are fun, (I'm a huge fan of Andreas Kling serenity-os), there is a lot of low hanging fruit for people to make their mark on the compiler. Also, I thought I understood Rust, but it's exciting when you start getting into the nitty gritty.
Once a language is mature, it's better to have various competing implementations, if just for the reason that no accidential implementation-defined behaviour sneaks into the specification.
How's this going for languages with multiple compilers, such as C++?
- lex differently;
- have different baselines for what code even compiles: e.g. in GCC an out-of-range hex escape sequence in an integer character constant generates a warning; in Clang it generates an error.
Additionally, for a long time on Windows MinGW's std::random_device()() always returned 0, being a real-world depiction of <https://xkcd.com/221/>. So you compiled for Linux with GCC and everything was fine; then you compiled for Windows with MinGW and silently something broke, which resulted in a suspiciously big number of hash collisions.
Then again, those are illustrations of a poorly written standard, not of the idea of a standard, which has multiple implementations, being bad.
My question is why not have a GCC front end for all major used languages?
This is only the case when there already is a standard. If rustc is the only Rust compiler in existence, it effectively defines what Rust is. With one compiler there is no meaningful difference between implementation details and "standard" language behaviour.
That's the point.
There are odd edge cases that rustc has accepted by accident. Without a second opinion it's hard to tell what was intended, and what is a compiler bug.
In fact, the Rust bug repository has thousands of opinions about thousands of things.
If that's what you want to do, that's great. If you experiment with new stuff, and it pans out, Rust itself might benefit from that.
Since your goal is implementing something that differs from "Rust", calling it "Rust", is misleading at best, I think is unethical, and given the intent, probably illegal in most of the world since "Rust" is a registered trademark... (IANAL but if you were implementing a frontend for Rust, you could maybe use it, but for an intentionally different language, doesn't sound like it)
> implementing something that differs from "Rust" (...) I think is unethical, and given the intent, probably illegal
I don't understand this statement. One of the contributors said earlier in the thread something that sounds opposed to your interpretation:
> For inconsistencies, we have stated in our FAQ that if GCC rust does not behave the same as rustc. Then it is a bug with GCC rust.
Also, "your code is illegal" is not very much an ethics argument in my book. Digital weaponry like mass-surveillance systems are mostly legal, while harmless ThePirateBay/PopcornTime are illegal.
> And if you disagree with the unilateral decisions of the rustc developers? "Go fork it or write your own"? Yeah that's what we're doing.
I think that the main value of implementing a new Rust frontend, is discovering issues in the Rust spec.
They seem to, however, disagree with some Rust specification issues, and creating an incompatible frontend, not with the intent of making the spec better, but rather just doing something different.
They are calling this different thing "Rust", which I believe is a misleading, and unethical thing to do. (Its as if I make my own language, and call it C++). I think this could also be illegal, since Rust is a trademark of the Rust foundation, which if they don't defend, e.g., in cases like these, makes the trademark irrelevant, e.g., allowing corporations to fork Rust, change the language, and still use the Rust name, cause they did not enforce it here. But as mentioned IANAL, my only point is that you probably want to be very careful in most juristictions in the world about using a trademark in this way.
Others seem to also believe that finding issues in the Rust spec is one of the most valuable things for Rust that can come out of this project. But the main devs haven't been able to point at issues they have filled about it in Rust upstream (as opposed to other projects like have implemented rust frontends before, like mrustc, rust-analyzer, rustc_codegen_gcc, etc. which have found many bugs and filled many issues that have been fixed, submitted patches, etc.).
> I've been reading comments in this thread and i wonder what actual arguments you have against gccrs,
I don't have any arguments against gccrs.
I've been looking for arguments in favor of gccrs, but was not able to find any.
Most arguments mentioned here are incorrect, e.g., gcc-rs being necessary to get rustc access to more targets (incorrect since rustc_codegen_gcc is a thing), gcc-rs resulting in Rust spec improvements (incorrect since they aren't filling any bugs / helping in improving the spec), etc.
If you have an argument in favor of gccrs, please go ahead, I am all ears.
One argument in favor of gcc-rs is related to bootstrapping; right now you need both a previous Rust compiler, as well as a C compiler, to compile Rust. With gcc-rs, you need only gcc. I don't personally think that the bootstrapping situation is onerous, but there are some folks who are looking forward to that.
I also don't think that because it compiles to C it automatically supports all of the platforms gcc does, but I haven't personally investigated that because I don't have any of that exotic hardware.
EDIT: oh yeah and the project itself describes this stuff here https://github.com/Rust-GCC/gccrs/wiki/Frequently-Asked-Ques...
GCC can be faster in some cases and despite other claims there are many platforms that only work with GCC, I was offered in the past a job to work on implementing code optimizations for gcc by a company that had such a embeded board platform - so if Rust wants to run everywhere C runs then the community should try to explain the fanboys that gcc is not a bad thing.
How?
The Rust compiler frontend already can use GCC as a backend.
This project - GCC rs - is a different frontend, which also happens to use GCC as a backend.
The number of targets and performance that both can have is the same.
So the argument "GCC can be faster than GCC" is illogical. You are talking about the same thing.
I wrote part of the reasons for why I am working on gccrs here: https://news.ycombinator.com/item?id=28368924
Overall I feel sad that this effort has been perceived as some kind of attack against Rustc and its community by some. This effort of mine dates back to 2014 and then I was able to get quite alot of rust working in a short time but the language changed far too much to keep up as a solo effort. Since late 2018 I restarted the effort and seriously almost started the track to develop the a gcc backend using libgccjit, it is 100% something i have considered and thought through.
I will be giving a talk on this project at LPC if you wish to hear more about my reasons please listen then https://linuxplumbersconf.org/event/11/contributions/911/
I don't interpret that to mean they intend to insert breaking changes (especially since another comment and their FAQ directly contradicted that idea), but rather that they may explore different ways of implementing things, which i think is a great idea.
> But the main devs haven't been able to point at issues they have filled about it in Rust upstream
Maybe they're busy actually working on something and don't have time to look for specific instances? Or maybe a lot of questions/issues have been documented internally are have not been sufficiently reviewed yet to be opened upstream? There's a lot of room for interpretation here, but i see no reason to assume bad faith on their part.
> If you have an argument in favor of gccrs, please go ahead, I am all ears.
It's been rehearsed over and over, but if you want to build an actual standard, having many eyes/implementations is a good thing. Feedback from people trying different implementation approaches is crucial to making a specification robust.
You can have 2 different version of the same compiler that makes 2 different things for the same code, or you can have a bugged compiler that on Thursday produces different output, I assume you notice now the problem with not having a standard and the documentation is "go read the compiler source code from tonight commit, yesterday code migtht not be fresh enough"
There are tons of embedded platforms that get rust support from this work.
There might be other value that a separate Rust frontend delivers over the official one, but this is not it.
Wouldn't both approaches produce the same result (if they ever succeed to implement the whole spec)?
In short, a big part of the motivation is a deliberate effort to decentralize Rust.
That, and 1. GCC historically generates better code than LLVM, and 2. GCC supports far more platforms.
That's quite a strong statement. What specifically do you dislike?
If alternative compilers had such a flag, you'd end up with code that was incompatible with rustc, leading to an ecosystem split. This is one of the major fears within the community about alternative implementations.
IIRC the GCC Rust developers have stated a desire for compatibility, and therefore I'm not sure that they would accept this flag either, but we'll just have to see I guess.
Yeah that was me I'm afraid. That said, I strongly disagree that -fno-strict-aliasing changes language semantics in an appreciable way, since using it to deliberately circumvent the aliasing rules still wouldn't be sanctioned by Rust. You'd just have a predictable, mostly acceptable form of "UB" rather than whatever glitter the compiler feels like farting into your face. If I was asking for a flag that broke existing code, I'd understand, but since this change is totally backwards compatible, I don't understand the objection.
EDIT, responding to yours: it was explained in the thread, at length: https://internals.rust-lang.org/t/add-rustc-flag-to-disable-... it's not backwards compatible. The very first post is the language team co-lead explaining:
> Whether or not rustc makes use of the codegen backend's support for optimizing &mut using noalias, by specification and defition &mut is still an exclusive reference. Various parts of the language and library depend on that exclusivity for soundness. &mut is not the mechanism you're looking for.
The truth of the matter is that I'm horrified by stacked borrows and what it represents, because it will make unsafe code extremely painful to write and extremely brittle. Rust needs a way to opt-out of these aggressive optimizations, like every other systems language ever has had for the majority of their lifespans. A function attribute would be acceptable, but the truth is, Rust is not open to any such enhancements for unsafe code. They seem hell-bent on enforcing "safety" on deliberately unsafe code, even if it breaks that code in subtle ways.
EDIT: I have no interest in arguing further. This is a hopeless and frankly rather disheartening topic for me. Rust has brought out more strong emotions from me than any other language I have ever used. I suppose why it matters to me is because I see such potential in Rust, and I feel it's being taken down the wrong path. But, that's just my opinion.
As the next sentence of that very first post said:
> There is a way to tell the language exactly what you want: you can use unsafe, raw pointers, UnsafeCell, and abstractions built atop them.
And again, this is not about optimization, this is about semantics. What you want is a different semantics, which is why it is not something that we would accept as a flag. Rustc does already let you change what optimizations are done to your code (trivially: -C opt-level=n). That is not an issue. This just isn't about optimization.
You don't seem to understand the concept of undefined behavior. What I'm trying to say is that even if rustc generates the correct output, the code could still officially be declared UB, just as it is now in debug mode. If it breaks logic that relies on the exclusivity of &mut, well, that's what UB does, it breaks things.
It is entirely an optimization option.
You're right that I think it would be nice if you could have multiple &muts created from raw pointers, but I'm not asking for that. The reason these things are issues at all is because Rust uses these references for things like RAII (e.g. &mut self in drop()), and there's no way to use raw pointers instead. If Rust provided a way to use raw pointers more easily in the places you need them, this would be a non-issue. But right now, the unsafe/safe boundary is very dangerous in Rust, so dangerous that I'm uncomfortable working in it even though I've worked in C and C++ for over a decade, and it's entirely a self-inflicted wound by the Rust devs.
Okay, now I am done here, like you said you were before this post.
? no it mustn't. what's the c++ abi
That's not really something they can do without hard-forking the language.
They either stick to what the reference implementation does, or don't. But as soon as they don't, it's essentially a forked language with incompatible nuances.
So rustc can already target _more_ architectures than this new GCC frontend, because it supports LLVM and Cretonne.
I think you mean Cranelift?