Rust support coming to GCC
This is very much an extremely experimental compiler and will still get a lot of changes in the coming weeks and months up until the release". See this article and this one for more details on the current status of gccrs.
Posted Dec 7, 2022 10:42 UTC (Wed)
by bmillemathias (guest, #54343)
[Link] (44 responses)
What is the purpose for GCC to provide it own rust compiler ?
Best
Posted Dec 7, 2022 11:00 UTC (Wed)
by geert (subscriber, #98403)
[Link] (20 responses)
Posted Dec 7, 2022 11:18 UTC (Wed)
by Tobu (subscriber, #24111)
[Link] (6 responses)
Posted Dec 7, 2022 14:42 UTC (Wed)
by mathstuf (subscriber, #69389)
[Link] (5 responses)
Posted Dec 7, 2022 15:29 UTC (Wed)
by TheGopher (subscriber, #59256)
[Link] (4 responses)
Posted Dec 8, 2022 0:53 UTC (Thu)
by tialaramex (subscriber, #21167)
[Link] (3 responses)
Like here's Rust's String class:
https://doc.rust-lang.org/std/string/struct.String.html
We get a discussion of the features, mentioning that Deref<Target=str> (ie you can use a String almost anywhere &str would work), explaining about UTF-8, how String works (e.g. capacity) and so on, we get a break down of all the methods on String, (and on &str because of the Deref I mentioned) with examples in many cases you can play with straight from your browser and links to the actual implementation of these features in fairly readable Rust.
Now here's the closest CPP Reference gets us:
https://en.cppreference.com/w/cpp/string/basic_string
That's a pretty intimidating wall of text, and it's that way because CPP Reference documents all C++ versions, which of course are incompatible, and so stuff appeared or disappeared in different versions and there are numerous exceptions, and the exceptions to those exceptions, as a result. It's also that way because C++ has a tremendous number of "string" types documented here.
We need to guess what we might be interested in and drill into individual methods like contains() to get to examples we can try, and so those examples can't realistically help us explore this type.
Maybe it's unfair to focus on Strings, since although they're a common idea C famously can't get them right so why should C++. Lets try a more fundamental type, char:
https://doc.rust-lang.org/std/primitive.char.html
versus
https://en.cppreference.com/w/cpp/language/types#Characte...
Wow, C++ even manages to have lots of char types. Of them char32_t is the closest to usable. But, I happen to know this documentation isn't sparse by mistake, these types just don't have any features. In C they wouldn't be able to have features and so perhaps out of perverse solidarity, they have no features in C++ either. As you can see the Rust char type has methods, constants, associated functions, and implements a bunch of traits.
Furthermore though, Rust provides documentation in this same style automatically for your own libraries. Here's the documentation for my LoadLetter type, which is an implementation of two I/O traits which just always fails.
https://docs.rs/misfortunate/1.0.0/misfortunate/struct.Lo...
So far as I can tell, if I write some C++ I don't get a CPP Reference page for it.
Fundamental concepts from Unsafe Rust could do with more documentation, but the vast majority of a team's effort and of most programmer's time will be spent with safe Rust, for which in my opinion Rust's documentation is in better shape than CPP Reference.
Posted Dec 9, 2022 16:54 UTC (Fri)
by TheGopher (subscriber, #59256)
[Link] (2 responses)
Posted Dec 10, 2022 14:07 UTC (Sat)
by draco (subscriber, #1792)
[Link]
But before we go there, did you notice that the pages can collapse down so you get a list of all the methods, and then you can only expand the things you want more detail on? That IMHO sounds very like the use case you're talking about. (I prefer to use the pages that way too, BTW.)
Posted Dec 12, 2022 14:15 UTC (Mon)
by tialaramex (subscriber, #21167)
[Link]
std::basic_string satisfies the requirements of AllocatorAwareContainer (except that customized construct/destroy are not used for construction/destruction of elements), SequenceContainer [[and ContiguousContainer (since C++17)]]
The tl;dr of those paragraphs of text is that the data in a std::string is definitely a slice, the same fact the Rust doc transmits by just mentioning that impl Deref<Target=str> for String
This difference is because C++ semantics are unenforced. If you mistakenly assumed a C++ std::list was a ContiguousContainer you may write software that's defective as a result, your last chance to realise the mistake is when consulting documentation. In Rust if you mistakenly thought LinkedList is a slice, it isn't, so your program just doesn't compile.
So if you rewrote the CPP Reference materials in Rust style they'd need the same information, but as a developer I don't need this information in Rust.
Posted Dec 7, 2022 11:32 UTC (Wed)
by JMB (guest, #74439)
[Link] (12 responses)
Posted Dec 7, 2022 12:36 UTC (Wed)
by nix (subscriber, #2304)
[Link] (11 responses)
Posted Dec 7, 2022 13:24 UTC (Wed)
by pbonzini (subscriber, #60935)
[Link]
Posted Dec 7, 2022 14:54 UTC (Wed)
by mathstuf (subscriber, #69389)
[Link] (9 responses)
Personally? I found GCC easier to hack on myself in the corners I've touched at least. Between the faster compilation and more "direct" coding style, pulling threads to implement a prototype for P1689[1] took a day or two in GCC. Meanwhile, I got lost in the abstractions LLVM contains for tracking dependencies and the various "holes" I was missing to get the information I needed seemed to involve coding up new modes to not require actual BMI files when encountering an `import` statement. Luckily, a more seasoned LLVM developer came around and managed to know where to put in the right bits (now in `clang-scan-deps` rather than the compiler itself).
Posted Dec 7, 2022 17:25 UTC (Wed)
by khim (subscriber, #9252)
[Link]
From practical POV sanitizers are much more important than standard modules or concepts. I'm not sure LLVM is strictly better for research purposes that gcc (number of papers is larger simply because LLVM license makes it safer to make proprietary forks), but it's not worse, at least. I would say gcc is main driving force if we look on C++ development while LLVM used for many more things.
Posted Dec 9, 2022 10:47 UTC (Fri)
by Wol (subscriber, #4433)
[Link] (7 responses)
Afaict (which isn't very far), GCC != clang. It's like comparing a pub kitchen to a hotel, they're in the same line of business, but one does MUCH more than the other.
Am I correct - GCC is the entire chain, front ends, optimiser, and back ends?
Whereas clang is JUST the C/C++ front end? You could replace GCC's C front end with clang?
LLVM as I understood it took IR and optimised/transformed it.
So in a discussion about Rust, Clang should be irrelevant. Okay, I was on the llvm mailing list until they got rid of it, and I gather Rust had problems because the - supposedly language independent - IR had a load of C-isms in it. Primarily because clang was the main/only real front end.
But in that case, isn't the Rust front end a *replacement* for clang, not a user of it?
Cheers,
Posted Dec 9, 2022 13:26 UTC (Fri)
by mathstuf (subscriber, #69389)
[Link] (6 responses)
Yes, because APIs to access parts of GCC at a time have historically been vetoed by RMS. There's now libgccjit, but that's not the same thing.
> Whereas clang is JUST the C/C++ front end? You could replace GCC's C front end with clang?
IIRC, this happened before: <https://dragonegg.llvm.org/>. Seems dormant/dead now though.
> LLVM as I understood it took IR and optimised/transformed it. […] Okay, I was on the llvm mailing list until they got rid of it, and I gather Rust had problems because the - supposedly language independent - IR had a load of C-isms in it. Primarily because clang was the main/only real front end.
Yes, but it has a number of C-like assumptions built into the IR. IIRC, Rust had trouble using `noalias` markers because the optimizers passes had bugs because C and C++ could not utilize them properly (and any problems were probably UB anyways…). GCC has had a Fortran frontend for many decades and probably has fewer such problems in its passes because Fortran aliasing rules are much closer to Rust's than C or C++ (AFAIK).
> So in a discussion about Rust, Clang should be irrelevant.
We're talking about the suitability of the compilers for research work in the context of language standards (in this case, C++), so the comparison is apt IMO.
Posted Dec 9, 2022 15:08 UTC (Fri)
by tialaramex (subscriber, #21167)
[Link] (5 responses)
In Rust, the only loop construct† is named loop and it's an infinite loop. Obviously in practice you use it with break (and perhaps continue) but the actual construct is literally an infinite loop. In C++ there are no infinite loops, the obvious syntax to write one is actually Undefined Behaviour in C++‡ as a result of the Forward Progress rule. So the LLVM design just didn't allow infinite loops, even though that's how Rust's loop works. This is a pretty nasty impedance mismatch.
† There's syntax for while and for loops, but they're literally sugar, early on they just get turned into a "normal" loop, with a break clause in the appropriate place so that they exit as expected.
‡ A C++ compiler can and will emit code that just skips an infinite loop you wrote on the rationale that it can't really happen as that's UB.
Posted Dec 11, 2022 15:27 UTC (Sun)
by gmatht (subscriber, #58961)
[Link] (4 responses)
Posted Dec 11, 2022 16:09 UTC (Sun)
by mathstuf (subscriber, #69389)
[Link]
In your example, if `BigNumber` is a stack variable whose address has not been given to "elsewhere", then it cannot make forward progress (and, if `signed`, will eventually hit UB anyways). If it's some global or the address has been passed elsewhere, there *could* be a thread that is watching it and therefore "do something" about it (though this thread's behavior is in considerable limbo; there's probably some corner case in the C++ standard about things like this).
Posted Dec 11, 2022 16:21 UTC (Sun)
by excors (subscriber, #95769)
[Link]
> * 6.9.2.2 Forward progress [intro.progress]
So I believe your "while(true){BigNumber++}" is violating that assumption and the compiler may remove the loop and execute the code that's after the loop, unless BigNumber is volatile or atomic (which is an easy way to make it legal and avoid any concerns about Turing completeness).
Posted Dec 11, 2022 19:40 UTC (Sun)
by Wol (subscriber, #4433)
[Link] (1 responses)
Loop, wait for an event, handle or pass off, repeat.
The whole point of it is you're meant to loop indefinitely ...
Cheers,
Posted Dec 11, 2022 20:10 UTC (Sun)
by ABCD (subscriber, #53650)
[Link]
So long as you make "forward progress" inside that loop, you are fine. The problems only arise if you don't do one of the following: I would presume that in your event handler, you are going to wait for an event somehow, which would require that you either call a library I/O function to see if you have events (and/or get the event information), access a volatile glvalue (in the case of a hardware event handler with memory-mapped I/O, for instance), or perform a synchronization operation or atomic operation (which is probably needed for thread safety if the events are being posted by another thread in the same application). In any of these cases, you have made forward progress in some manner, using the standard's definition of "forward progress".
Posted Dec 7, 2022 12:15 UTC (Wed)
by Karellen (subscriber, #67644)
[Link] (6 responses)
Because having multiple implementations of languages and runtimes is generally a good thing. See also C, C++, Java, C#/.NET, Python, Lisp, Haskell, Fortran, Javascript, Bourne shell - you know, 90% of all the major programming languages in heavy use. See also also, mail servers & clients, web servers & clients (browsers), XMPP servers & clients, TCP/IP implementations, SQL engines, image encoders/decoders/editors, .doc/.odt (word processing) editors/viewers, .xls/.ods (spreadsheet) editors/viewers, etc... Being forced to rely on a single supplier isn't the best of all possible strategies. Even if those suppliers are FOSS. See, for example, gcc around 1997. Sure, the devs forked egcs eventually, and that became the next gcc eventually, but while that was going on there was a fair amount of concern about the direction of gcc generally. Having another Free compiler around that was not experiencing organisational difficulties would have been better for C/C++ developers at the time.
Posted Dec 7, 2022 15:17 UTC (Wed)
by mathstuf (subscriber, #69389)
[Link] (5 responses)
FWIW, it seems like Haskell standardization has faltered a bit because GHC is just so far ahead of any other implementation. Haskell might effectively be a single-implementation language today.
Article about it: https://reasonablypolymorphic.com/blog/haskell202x/
Posted Dec 7, 2022 16:17 UTC (Wed)
by bredelings (subscriber, #53082)
[Link] (4 responses)
Most of the documentation for language features not in the 2010 report is actually in "Note" comments inside the compiler (GHC) source code.
I had previously assumed that all languages had multiple compilers + a standard that describes whether a compiler conforms.
But of course developing a standard takes a lot of work that would have to be done by volunteers.... plus the ability to solve new kinds of constraints is a subject of ongoing research, so I can see that people might not want to specify exactly what the compiler accepts, since it might be able to accept more stuff tomorrow.
Posted Dec 7, 2022 16:46 UTC (Wed)
by farnz (subscriber, #17727)
[Link]
To some extent, external standards are a product of the era where compilers were closed-source products you obtained (bought, supplied with hardware) from a vendor, and not portable between systems.
If you have to rely on Sun's C compiler when compiling for one system, Microsoft's when compiling for another, and IBM's for a third system, and you can't use one compiler for all three systems, you need something you can look at to determine why your "portable" software behaves differently on different systems, and determine whether the compiler is at fault ("standard section 9.2.4.5.1 says this, your compiler has done that") or whether your source code is at fault ("standard section 9.2.4.5.1 says this construct means one of these three things, I've assumed it'll be thing 1, but on IBM's compiler it's thing 2").
Now that it's reasonable to port language implementations between systems, rather than relying purely on vendor compilers, the need for a standard is less pressing; if IBM's C compiler is good enough to compile GCC for the system you're working on, you don't need to care about how the standard says your source should be interpreted, merely about how GCC interprets it. If you're happy with GCC's interpretation of your source, but not with the vendor compiler on a given platform, you simply replace the vendor compiler with GCC, and you're done.
Posted Dec 7, 2022 17:32 UTC (Wed)
by khim (subscriber, #9252)
[Link] (2 responses)
Note that GHC couldn't compile standard-compliant Haskell anymore because monad is an applicative in GHC, but not in any standard Haskell. Note: I'm not saying it's bad change, but the fact remains: it's not possible to just take any random standard Haskell program and hope to run it on GHC. That's fine, most languages have extensions. It's when you stop supporting standard-compliant programs you can say that standard is well and truly dead. Like happened to Pascal in the end of last century and now happens to Haskell.
Posted Dec 7, 2022 20:49 UTC (Wed)
by mathstuf (subscriber, #69389)
[Link] (1 responses)
What would break from that?
Posted Dec 7, 2022 21:23 UTC (Wed)
by khim (subscriber, #9252)
[Link]
Tutorials for one. When you open the appropriate chapter, type in the example and it blows up in your face? That's not very inviting experience. Now, the error message is somewhat helpful and if you know what you are doing it's easy to fix, but still… most languages value the ability to type and run fully standard-compliant programs from tutorials a bit more than that.
Posted Dec 7, 2022 14:44 UTC (Wed)
by zorro (subscriber, #45643)
[Link] (9 responses)
Posted Dec 7, 2022 15:31 UTC (Wed)
by TheGopher (subscriber, #59256)
[Link]
Posted Dec 7, 2022 15:37 UTC (Wed)
by mathstuf (subscriber, #69389)
[Link] (2 responses)
Posted Dec 7, 2022 19:42 UTC (Wed)
by philbert (subscriber, #153223)
[Link]
Posted Dec 7, 2022 19:53 UTC (Wed)
by Lionel_Debroux (subscriber, #30014)
[Link]
Going commercial-only (though still GPL, obviously) for PaX+grsecurity enabled PaXTeam and spender to start making a living from their work, which they couldn't do in 17 years offering the software for public download at no cost in donation-only mode, then hire additional security researchers to further improve defenses and find more security issues in software and hardware, then additionally sponsor work on this piece of FLOSS useful to the general public.
Posted Dec 7, 2022 22:54 UTC (Wed)
by njs (subscriber, #40338)
[Link] (4 responses)
> As the source of the GCC plugin infrastructure in the Linux kernel and nearly all of the GCC plugins adapted for inclusion in the upstream Linux kernel, we too immediately spotted the importance of this problem and set out to ensure both those plugins as well as the security features built-in to GCC itself are able to instrument code from all languages supported by the Linux kernel with compatible and consistent security properties.
I wish the project luck, but if you aren't in the specific situation of needing to protect your investment in custom GCC plugins compiling a mixed C++/Rust code-base then it's probably not super relevant to you.
Posted Dec 9, 2022 18:27 UTC (Fri)
by developer122 (guest, #152928)
[Link] (3 responses)
Posted Dec 9, 2022 20:02 UTC (Fri)
by khim (subscriber, #9252)
[Link] (2 responses)
Indeed. But it's worse than that: in the we have got both proprietary plugins and also a full alternative compiler which is now endangering gcc itself It's funny how these two things kinda cancel themselves out in
Posted Dec 9, 2022 21:26 UTC (Fri)
by developer122 (guest, #152928)
[Link] (1 responses)
Posted Dec 10, 2022 13:14 UTC (Sat)
by Wol (subscriber, #4433)
[Link]
Closed-source plugins for General Purpose problems are BAAAAD. But for a proprietary piece of hardware? I'd rather not, but if that's classed as a "necessary evil", so be it.
Cheers,
Posted Dec 8, 2022 5:22 UTC (Thu)
by alison (subscriber, #63752)
[Link]
To have different bugs than rustc.
Is it not possible that GCC supports more compile-time options than rustc? Or has better optimization at IR level?
Posted Dec 8, 2022 14:02 UTC (Thu)
by zamnedix (guest, #159696)
[Link] (1 responses)
Posted Dec 9, 2022 18:32 UTC (Fri)
by developer122 (guest, #152928)
[Link]
Posted Dec 9, 2022 23:40 UTC (Fri)
by Karellen (subscriber, #67644)
[Link] (2 responses)
Also, if you only have a single compiler for a language, which is written in that language, you are vulnerable to a trusting trust attack. If you have multiple compilers, you can perform diverse double-compiling where you bootstrap one compiler with a second compiler of completely different origin. Even if both are backdoored, and even if both are capable of hiding their backdoors in each other (very unlikely), using gccrs to compile rustc would insert the gccrs backdoor inside the new rustc, which would give you a different binary from compiling rustc with itself, which you could then detect.
Posted Dec 23, 2022 11:33 UTC (Fri)
by sammythesnake (guest, #17693)
[Link] (1 responses)
If you're planning an attack against Compiler A compiled with Compiler B, you're probably imaginative enough to also consider A-compiles-A, B-compiles-A and B-compiles-B, too...
Of course, somebody trying to detect such an attack could consider using a third compiler, potentially a much earlier version of A or B if neither language has a third separate implementation. Every additional compiler/language involved adds considerable challenge to the attacker.
It's an arms race in sneaky code subversion...
Posted Dec 23, 2022 18:13 UTC (Fri)
by Wol (subscriber, #4433)
[Link]
Doesn't stop the trojan being hidden in plain sight in all the Forth source ... :-)
Cheers,
Posted Dec 7, 2022 21:43 UTC (Wed)
by amarao (guest, #87073)
[Link] (2 responses)
It's the second best news after Rust itself.
Posted Dec 9, 2022 18:40 UTC (Fri)
by developer122 (guest, #152928)
[Link] (1 responses)
Posted Dec 9, 2022 19:11 UTC (Fri)
by amarao (guest, #87073)
[Link]
The main thing which should happens, is that people stop to associate Rust with rustup/cargo. C is not GCC nor CLANG, the same for Fortran and many other venerable languages. Having clean separation between specification and implementation is real virtue.
Posted Dec 8, 2022 0:13 UTC (Thu)
by Subsentient (guest, #142918)
[Link] (17 responses)
Is it a duplication of effort? Yes. Does the functionality already exist in another project? Yes.
We *want* a completely untethered rustc implementation. That's part of the point!
I don't *want* the rustc reference implementation to have a total chokehold on the language, that's bad for a systems language that needs to run in many targets with odd requirements.
So please, stop asking why, stop aggressively trying to kill independent implementations, and start understanding that the total independence and duplication of effort is *part of the point*.
Posted Dec 8, 2022 1:42 UTC (Thu)
by Subsentient (guest, #142918)
[Link] (1 responses)
For example, can you give me any documentation on when, exactly, implicit reborrows occur?
Sometimes I wonder if part of the reason Rust devs especially seem to oppose independent compilers is that they know these bugs will be brought into more public view and they're embarrassed, because they added features for convenience without any forethought for documenting those behaviors consistently and completely.
Posted Dec 8, 2022 8:47 UTC (Thu)
by tialaramex (subscriber, #21167)
[Link]
I think the heart of the problem is something which hasn't occurred to you at all because of a C background. Rust's compiler accepts a _subset_ of legal Rust.
This is the other option for Rice's theorem, which avoids the catastrophe of C++ and to a lesser extent C, in which sure, the compiler definitely accepts all legal C++ / C but alas it also accepts myriad random other programs with no meaning, and provides you with no diagnostics, they just do... something.
In Rust all the programs that compile are legal Rust. Some of the programs which don't compile are legal Rust too, which is unfortunate, but hey, you're a human, you can fix the problem, whereas with the C++ approach you don't even know there's a problem.
Posted Dec 8, 2022 3:40 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (3 responses)
Because it can split the ecosystem if one of the implementations can't keep up with new features. Which is a real problem because Rust is still evolving rapidly.
Posted Dec 8, 2022 16:13 UTC (Thu)
by Wol (subscriber, #4433)
[Link] (2 responses)
Too many specs to me feel as if they're written to describe what happens.
A good spec attempts to be complete and consistent. And sensible.
?Best done? by compiling a truth table and making sure all possible values are, at a minimum, addressed.
As a perfect example of a cock-up, let's take the following truth table from the "gentoo compile a kernel" set up.
Flag A - is there a separate boot partition?
If flag A is false, flag B is meaningless so that's two out of four accounted for.
What's the point of having the options if the only thing that works is the default? Never mind the fact I wanted "A = true, B = false" because I did NOT want the automated install stomping over my live boot partition and leaving me with a system that wouldn't boot.
Never mind that the suggested work-around "to achieve the same effect" was to set the "don't install" flag - which not only doesn't put the install files in the /boot directory, but actually caused the build to blow up with "can't find input files" ...
I know they're volunteers, but a little bit of common sense and quality control (and pride in their own work) wouldn't go amiss...
Cheers,
Posted Dec 8, 2022 18:54 UTC (Thu)
by rgmoore (✭ supporter ✭, #75)
[Link] (1 responses)
Too many specs to me feel as if they're written to describe what happens. I think this is a key thing having multiple implementations is supposed to address. If you have only one implementation, it's really easy to slip into treating that implementation as the primary specification, with the written specification as nothing but a description of the implementation. Having multiple implementations makes that less likely.
Posted Dec 8, 2022 21:02 UTC (Thu)
by amacater (subscriber, #790)
[Link]
Posted Dec 8, 2022 15:59 UTC (Thu)
by rgmoore (✭ supporter ✭, #75)
[Link] (5 responses)
Having multiple, independent implementations complicates things. You can have one main branch that still makes most of the decisions, in which case everyone else is playing catch-up and the implementations aren't really equal. You can have each branch free to come up with its own new ideas, in which case you get different dialects, each with their own quirks. Or you can have some kind of bureaucratic standardization process, which will slow language development.
In practice, you'll probably have some mix of the three; that seems to be what happens with languages like C. There will be a formal, standard-defined version of the language, but compiler writers will keep trying to expand the language with incompatible, non-standard extensions. Eventually, the standards committee will have to sort through the extensions and try to convert them into a new version, but it will lack the coherence of having a single implementation with some vision behind it.
Posted Dec 8, 2022 17:10 UTC (Thu)
by koh (subscriber, #101482)
[Link] (4 responses)
> but it will lack the coherence of having a single implementation with some vision behind it.
Whether there is any coherence in current rustc's development is still an open question. The C (and also C++) standards committee(s) have members from several unrelated interest groups, each of which either prefer the semantics of different (sets of) compilers or have no clear preference at all. This makes for a more balanced discussion on the pros/cons of a particular approach because (ideally) there is no "bubble" all committee members share. Whether that need for a compromise of technical, backwards-compatibility and visionary constraints has been taken into account is hard to convey when the group of people responsible for such features has only the single implementation "rustc".
So language development may be slower, though personally as a mainly C++ developer, it is already too fast for me to keep up. I've only recently looked at C++20 ranges/views and will not learn how to write (a correct return type of) coroutines anytime soon - and the next C++23 is ready soon... I'd be interested to hear about examples of both, how the current Rust development model actually produced coherent parts of the language and also where breaking revisions needed to be done. Without such kind of evaluation, I don't think the "it's more complicated to have lots of implementations" argument is going to be strong.
Posted Dec 8, 2022 20:18 UTC (Thu)
by hunger (subscriber, #36242)
[Link] (3 responses)
We get an implementation of any new feature to play with in the nightly compiler builds (and those are actually easy to install and play with!). These features get promoted to stable when everybody agrees that they are good (the tools used are available to everybody!). Usually this promotion involves a crater run: All publically available rust code is build to see if something breaks due to the changes.
So we get one or two new features per compiler release every 6 weeks that are tested, work and did not break any (known) existing code. I find that much easier to digest than the "C++ spec drops" every couple of years with an overwhelming list of new things -- many of which incomplete -- that I can not use in my project since my compiler does not support them yet.
Posted Dec 8, 2022 21:11 UTC (Thu)
by mbunkus (subscriber, #87248)
[Link]
Posted Dec 8, 2022 22:01 UTC (Thu)
by tialaramex (subscriber, #21167)
[Link] (1 responses)
It's one thing that GCC, Clang and MSVC need their own modules implementation, quite another that each of the three needs to write their own functions to format containers of things. No benefit accrues to C++ programmers from three different but hopefully equivalent implementations of these library features. At best you wasted 2x the effort, at worst now they behave slightly differently and so programmers need to compensate for that. So Rust (as far as I know) avoids that, GCC Rust won't re-implement Vec and Eq and Iterator and so on.
I also think the Rust model, though not always faster, is just more effective. WG21 (the "C++ Committee") has these periodic meetups to make a lot of its decisions. The argument is that if you're all together in Hawaii (for example) this lets you focus and so you can be more productive. But there are huge problems not only in terms of accessibility/ equity (if you're a Google employee in San Francisco then Hawaii is maybe affordable even if work isn't paying, not so much for a Polish teenager...) but because this crushes down the decision making process. Some people are going to hear about your idea for the first time an hour before they vote that it's not interesting and the committee doesn't want to see it next time. Would it have helped if your example was better motivated? If you'd worn tighter pants ? If you'd laughed at their joke ? Maybe they were just hungry and you'd have had better luck after lunch.
I have opinions about Rust RFC #3334 (Niches). They're strong enough opinions that I wrote something on the ticket and I might do it again. If you scheduled a specific video chat I might make it. Would I go to Hawaii? No. Fortunately Rust doesn't make decisions by flying to Hawaii.
Other people have opinions about that RFC. Instead of listening to them over the course of an hour, maybe while slightly hungover, I have been able to read them at my leisure over days, sometimes rolling an idea back and forth in my mind. I think some of the opinions are more right now than when I first saw them. I have questions I didn't have when the process began. I am confident WG21 could not replicate this process and get work down on their committed schedules.
Posted Dec 8, 2022 23:27 UTC (Thu)
by mathstuf (subscriber, #69389)
[Link]
Posted Dec 8, 2022 19:58 UTC (Thu)
by hunger (subscriber, #36242)
[Link] (4 responses)
That was the value proposition I also saw in gcc-rust. Then I saw a presentation at the linux plumbers conference about how they want to ease maintenence by using the rustc compiler crates for things like the borrow checker (once they can actually compile those).
How independent are two compilers when they share implementation of core parts like the borrow checker?
Posted Dec 8, 2022 22:47 UTC (Thu)
by mathstuf (subscriber, #69389)
[Link] (3 responses)
Also, the rules for Rust are (basically) "`&mut` is unique and cannot coexist with any `&` at the same time". The borrow checker is an imperfect tool to verify this and, as such, more of an implementation detail (like ADL lookup in a C++ compiler might be; as long as the *rules* are enforced, the implementation isn't all that important). Note that this new implementation is already a parallel one of the existing borrow checker and doing the work any GCC one might have done anyways. So I think it's still interesting for two frontends to send information to this to check "is it allowed?".
Posted Dec 9, 2022 9:29 UTC (Fri)
by tialaramex (subscriber, #21167)
[Link] (2 responses)
Rust chooses to answer conservatively, Don't Know counts as No. All three borrow checkers, the one in Rust 1.0, the current one with Non-lexical lifetimes, and Polonius, are conservative, but each increases the range of correct Rust programs which successfully compile over the last.
The conservative choice offers safety, which is Rust's priority, at a cost of programmer inconvenience, which can be iteratively improved upon by working on the borrow checker. Thus, I believe Rust can and should specify that the actual rules are (basically) as you describe, but with a clarifying note that since these are semantic rules any compiler must be conservative. Maybe the note can specify that a conforming compiler must at least be able to allow X where X is some sane baseline of borrow simplicity.
Posted Dec 9, 2022 13:11 UTC (Fri)
by amacater (subscriber, #790)
[Link] (1 responses)
Posted Dec 9, 2022 15:26 UTC (Fri)
by tialaramex (subscriber, #21167)
[Link]
Rust's stability promise has a number of limitations, the one crucial here is that you don't get to depend on bugs. So if the borrow checker, no matter which one, was mistakenly allowing an invalid construction, Rust won't keep that working in future versions.
Posted Dec 8, 2022 22:56 UTC (Thu)
by jhoblitt (subscriber, #77733)
[Link] (1 responses)
Posted Dec 9, 2022 13:12 UTC (Fri)
by mathstuf (subscriber, #69389)
[Link]
I also suspect the pool of interest in doing the "Ada compiler in Rust", "Fortran compiler in Rust", etc. porting projects is low enough to stall a lot of progress.
Posted Dec 9, 2022 9:44 UTC (Fri)
by Skallwar (subscriber, #138105)
[Link]
Rust support coming to GCC
Rust support coming to GCC
The number of targets supported by gcc is much larger than the number of targets supported by the standard Rust compiler.
There is much better success achieving these goals (access to more targets) by getting GCC integrated into rustc as a backend. Besides LLVM, rustc master has in-development backends for Cranelift (faster debug compiles) and GCC (access to architectures that don't have LLVM support). Here are rustc-codegen-gcc progress reports, for comparison.
Rust support coming to GCC
Rust support coming to GCC
Rust support coming to GCC
Rust support coming to GCC
Rust support coming to GCC
Rust support coming to GCC
Rust support coming to GCC
Rust support coming to GCC
LLVM is tailored to the needs of industrial stakeholders - so suitable for mainstream ...
and thus lacking in respect of research.
Concerning the way to make Rust part of GCC I am always in favour of competition.
For me it is not that clear which way is most reasonable:
project gccrs being topic here making rustc in C++ (which I am favouring currently) or
project rustc_codegen_gcc to extend rustc to be able to use GCC as backend.
Rust support coming to GCC
LLVM is tailored to the needs of industrial stakeholders - so suitable for mainstream ...
and thus lacking in respect of research.
I am a massive GCC booster, but this is just a bizarre statement. The insides of LLVM are (or, rather, have a reputation as) sufficiently much cleaner than GCC that most research work has been done with LLVM as a basis for many years now (as any quick random check of papers and research-grade experimental compilers shows). I thought this was widely enough known (and uncontroversial) that finding people claiming the opposite is weird, like seeing someone who says that Bill Clinton is still the US president. GCC *was* the major compiler research platform... in the late 90s. It is no longer the late 90s.
Rust support coming to GCC
Rust support coming to GCC
Rust support coming to GCC
Rust support coming to GCC
Wol
Rust support coming to GCC
Rust support coming to GCC
C++ not Turing Complete?
C++ not Turing Complete?
C++ not Turing Complete?
> The implementation may assume that any thread will eventually do one of the following:
> - terminate,
> - make a call to a library I/O function,
> - perform an access through a volatile glvalue, or
> - perform a synchronization operation or an atomic operation.
> [Note: This is intended to allow compiler transformations such as removal of empty loops, even when termination cannot be proven. - end note]
C++ not Turing Complete?
Wol
C++ not Turing Complete?
Rust support coming to GCC
Rust support coming to GCC
Rust support coming to GCC
Rust support coming to GCC
> As far as I can tell, Haskell is actually a language defined by the compiler, not a language defined by an external standard.
Rust support coming to GCC
Rust support coming to GCC
Rust support coming to GCC
Rust support coming to GCC
Rust support coming to GCC
Rust support coming to GCC
Rust support coming to GCC
Rust support coming to GCC
Rust support coming to GCC
[...]
> we decided to fund the first year of a full-time developer for the work ourselves.
[...]
> Embecosm graciously offered to contribute to the effort by handling Philip's employment and, at no cost to us, providing project management services to help ensure the project's success.
- https://opensrcsec.com/open_source_security_announces_rus...
Rust support coming to GCC
Rust support coming to GCC
gccrs, though.Rust support coming to GCC
Rust support coming to GCC
Wol
Rust support coming to GCC
Rust support coming to GCC
Rust support coming to GCC
Rust support coming to GCC
Rust support coming to GCC
Rust support coming to GCC
Wol
Rust support coming to GCC
Rust support coming to GCC
Rust support coming to GCC
To all the "why bother" rustaceans
Same thing with GCC and LLVM for the most-part, excluding some odd CPU targets.
Do you think we should stop working on GCC because LLVM exists? What about vice-versa?
To all the "why bother" rustaceans
So much of more advanced Rust can only be learned via trial and error, obscure slightly-wrong Stack Overflow answers, and reading the rustc source code.
That is a big, big problem, at least in my book.
To all the "why bother" rustaceans
To all the "why bother" rustaceans
To all the "why bother" rustaceans
Flag B - automount said boot partition before modifying?
If flag B is true, that's what you'd expect, fine, that's the default.
If flag B is false - the build blows up and refuses to run.
Wol
To all the "why bother" rustaceans
And you shouldn't need an alternative implementation (other than for bugs in the compiler) if the spec is done properly.
To all the "why bother" rustaceans
To all the "why bother" rustaceans
To all the "why bother" rustaceans
To all the "why bother" rustaceans
To all the "why bother" rustaceans
To all the "why bother" rustaceans
To all the "why bother" rustaceans
To all the "why bother" rustaceans
To all the "why bother" rustaceans
To all the "why bother" rustaceans
To all the "why bother" rustaceans
To all the "why bother" rustaceans
Rust support coming to GCC
Rust support coming to GCC
Rust support coming to GCC