Hacker News Reader

Comment by masklinn | Hacker News Reader

One reason is that having multiple implementations can be useful to ferret out issues, a second is that the gcc framework wants to be a home for lots of language and that’s probably the reason why this was started, but the ecosystemic benefit is that gcc has a lot more (and more mature) support for rarer architectures and systems, and historically when companies provide a custom compiler for their weird-ass platform they do so using GCC (if only because it’s been there for way longer).

So an eventual gccrust would allow using rust on a much wider set of platforms, which is nice.

View on HN

Overall 2 major question come up about GCC Rust and they are not easy to answer but here is part of my perspective on the issue.

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.

> One reason is that having multiple implementations can be useful to ferret out issues,

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?

I have literally had to read compiler source code to find out Rust behavior before, more than once. That should never happen. The more implementations of a language there are, generally speaking, the better understood a language is. C++ has only benefited from having multiple compilers. 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 have literally had to read compiler source code to find out Rust behavior before, more than once.

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?

Having multiple implementations is a sign of a healthy programming language. C++, Rust's primary competitor in this space has multiple implementations and all are used by somebody. In fact, if rust as a language cannot deal with multiple compilers (ecosystem doesn't allow it as you described by your crates.io) then I don't see how it can overtake C++.

> if rust as a language cannot deal with multiple compilers (ecosystem doesn't allow it as you described by your crates.io)

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.

> Having multiple implementations is a sign of a healthy programming language

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)

> I have literally had to read compiler source code to find out Rust behavior before, more than once. That should never happen.

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.

Plus I see the main value of GCC Rust in helping improve the Rust spec, so all bugs uncovered are definitely worth fixing.

I don't know of anything with rust, but e.g. the csmith project fuzzing three C compilers has been extremely effective at finding bugs by using disagreement between them as a litmus test (it works by generating C programs which are guaranteed to be standards-compliant but with an unknown output and comparing the execution outputs between the compilers).

Given that "Rust is the spec", and it changes on a daily bases, fuzzing it vs GCC Rust would give you a lot of disagreements, that would only tell you about the thousands of ways in which GCC Rust is not conforming with Rust.

I'm not sure what this tells you about Rust. By definition, it is conforming with itself.

Things that have been declared stable do not "change on a daily basis" though.

When was the latest Rust stable release - every 6 weeks - that did not change the "spec" at all, e.g., by adding new stable features or standard library APIs ?

It is true that on a six-week basis we add new things. I should have been more specific, haha. The point is that the language does not make daily breaking changes, which is a reputation that we still sometimes have even after all of these years of no longer doing so.

That said, you are still right that it is a thing that the gcc-rust developers will need to keep up with.

In any case, one could consider the Rust epochs as main synchronization points anyway.

I would not, because new things land in most editions, so it’s not like a particular edition refers to a stable subset of the whole language.

True, however with the enterprise hat I see epochs as LTS versions worthy to be the ones on CI/CD pipeline.

I think LTS versions are great, but see them as something very distinct from editions. It is something I would like to see us have eventually.

>> Given that "Rust is the spec" . . .

>> 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?

The root answer is the same as with a specification, which can also have bugs: the authors make this determination.

If you think you found a bug: you just open it.

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.

The implementation shouldn't be the spec. Rust has a reference.

There is some really active discussion in the unsafe code wg repo by someone who is building an alternative compiler and has questions about corner cases. They largely seem like fruitful discussions.

These discussions are worth having.

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).

Agreed completely.

Reply on news.ycombinator.com