Looking for students to help build GCC-Rust as part of GSoC 2021

announcements
#1

I posted the following announcement to users.rust-lang.org and it was suggested I also take it here, sorry if such cross-posting is not desirable:

GNU Compiler Collection (GCC), is looking for students who would help build its Rust front-end and get paid for it under the Google Summer of Code (GSoC)program.

The Google Summer of Code is opened to students accepted into a post-secondary academic program which, once accepted, will work on projects which are supposed to take approximately 175 hours over 10-week coding period in June, July and August. If they successfully complete it, Google will pay them a stipend ranging from USD 1500 to USD 3300 depending on where they live. More information on the program is at its official site: https://summerofcode.withgoogle.com/

GNU Compiler Collection has applied as a mentoring organization and we are especially looking for students willing to take up projects on our upcoming Rust front-end. If interested, please look at our page for interested students: SummerOfCode - GCC Wiki

You will find two specific Rust ideas for a GSoC project (improving debugging experience and enhancing dead code analysis) on the page but we are always opened to consider those that students come up with themselves. The compiler, including the Rust front-end, is written in C/C++ and the work is likely to be challenging but rewarding beyond just the stipend.

Please consider applying if you are a student. We will be also very grateful if you can help us to spread the word about this opportunity so that it reaches more potential participants.

If you have any questions, feel free to reach out to the entire GCC community by posting an email to our mailing list gcc@gcc.gnu.org (and put "GSoC" to the subject somewhere). If you prefer to ask just me, I’ll also be glad to answer any questions sent to mjambor@suse.cz.

21 Likes
#2

[Note: speaking only for myself, not for any team or wearing any official hat here.]

Internals is a forum for the development of Rust (the language, libraries, and official implementation). In my opinion, I don't think it's appropriate to use internals for discussion or announcements about an alternative unofficial Rust implementation. (I don't know whether it's appropriate for users or not; I'm only commenting about internals.)

1 Like
#3

[I am speaking for myself, not as a member of the moderation team.]

Nobody seems to have treated conversations about mrustc or rust-analyzer as off-topic, and neither of those are official Rust projects (based on a cursory search of Internals, and based on the fact that neither of them use the rustup release channels or rust-lang GitHub organization).

More generally, if the Rust language is going to have high-quality, third-party implementations, then those implementations need to have their voices heard during language design discussions. Excluding them would basically send the message that the leadership doesn't want them to exist at all, since allowing them to speak where the language team will hear them is the least we can do to help.

If Internals isn't the right place for this sort of inter-implementation collaboration, then what place would be better?

38 Likes
#4

I think it's fine here as well, personally. Development of Rust ≠ development of rustc ¯\_(ツ)_/¯

6 Likes
#5

[Note: speaking only for myself, not for any team or wearing any official hat here.]

rust-analyzer is official, and there's ongoing work to distribute it via rustup. That RFC specifically says "We would like to (eventually) avoid having two implementations of the Rust compiler to support, one in rustc and one in rust-analyzer." To that end, rust-analyzer is aligned with the design of rustc, and tries to avoid duplication. Conversations about rust-analyzer directly, or about language/library proposals related to rust-analyzer, seem entirely on-topic by any criteria we might use. (For instance, I've seen discussions here, on Zulip, in RFCs, and various other places about trying to make the language easier to parse and analyze quickly.)

mrustc has some fairly unique positioning: it's generally held up as a method to bootstrap your way to rustc from scratch, to avoid having to work your way up through the OCaml versions of rustc. It's not official, but it serves a key purpose as part of rustc's bootstrappability, and it doesn't affect the broader Rust ecosystem (e.g. I've never seen any proposal for crates in the Rust ecosystem to make themselves compatible with the version of Rust supported by mrustc). I think the implementation of mrustc itself is not on-topic here, but if there were Rust language/library changes that would help with bootstrappability or similar, those would probably be on-topic.

We also regularly have discussions about other code-generation backends such as rustc_codegen_cranelift (which has official support), and rustc_codegen_gcc (which I hope to see officially supported in the future). And discussions about language collaboration across those backends are on-topic; for instance, discussions about SIMD or asm! take the capabilities of those backends into account. In general, I think we're fairly open to collaboration.

Along the same lines, I personally think that discussions about the Rust language/libraries that make reference to other implementations would potentially be on-topic here (depending on the nature of those discussions), but the actual implementation of an alternative compiler wouldn't be.

(To use GCC and LLVM as an analogous set of implementations, I would think that "let's talk about how GCC and LLVM can collaborate on aspects of C implementation" would be on-topic in either GCC or LLVM or C standardization spaces, but "let's talk about the implementation and get people to work on it" would only be appropriate for the corresponding implementation's spaces.)

I'm hoping that clarifies my previous post, and sounds relatively reasonable. In any case, I don't speak for the forum in any official capacity, and I'm not speaking for any Rust team here either.

4 Likes
#6

Well, judging by some of @josh's recent Reddit comments ([1], [2]), I think he doesn't want third-party implementations to exist at all – at least unless they can reach feature parity with rustc, which he seemingly isn't optimistic about in GCC's case.

Sorry to put words in someone else's mouth, but it feels like important missing context.

1 Like
#7

@comex I did not wish to bring that up in this thread, as I didn't feel it appropriate given the origin of this thread, and I'm not looking to stir anything up in that regard. Those comments were on-topic in that Reddit conversation; I don't think they're on-topic here. The only reason I posted here at all was that the original post led with some uncertainty of whether this thread was on-topic here, and it seemed appropriate to comment on that.

Also, I'm not pessimistic about GCC in particular; on the contrary, if any project could successfully build an alternative implementation, it'd be GCC. I have a great deal of respect for the GCC project. I'm just sad about duplicated work, and deeply apprehensive about the potential for ecosystem fragmentation.

But in any case, I felt it important to clarify that I wasn't expressing any kind of official position. My posts in this thread should only be taken as personal opinions.

2 Likes
#9

It's official now, as of May 29, 2020. But it was discussed many times before that date while it was still an unofficial project. No one complained about it then.

GCC Rust fills that need as well!

Anyway, Rust is striving towards having a formal specification. Multiple Rust (frontend) implementations is critical to having a good formal specification. You need different people looking at the same spec from different angles to find holes and bugs in the spec. And I'm not even sure what the point of a formal specification is if only one Rust implementation exists... And before the spec exists, it helps to have multiple people implement the Rust language so that they can all contribute to the formal specification; each implementor will have some different insights based on their different implementations.

21 Likes
#10

The internals forums is meant for:

Discussions around the design and implementation of the Rust programming language.

GCC Rust is an alternative implementation of the Rust programming language. How are discussions about it off-topic? Just because it is not "official" doesn't mean it should not be able to leverage the community forums.

12 Likes
#11

Let's be more welcoming.

I think we should be supportive of alternative Rust implementations. This forum is where people interested in compiler internals are likely to be, and the post is about a serious effort by GSoC and the GCC community. I am very happy about this initiative.

28 Likes
#12

Well, future versions of rustc are also ‘different implementations’. A formal specification may clarify which behaviours are part of the contract and will be preserved in future versions, and which are implementation details. Relying on surveying publicly available code can only get you so far. Having a formal specification can be valuable even if there is only ‘one’ implementation.

I otherwise agree entirely, but it’s worth keeping this in mind.

1 Like
#13

Perhaps discussing technical aspects of GCC internals may be best done elsewhere; however, this post is only an announcement that I believe can be quite an opportunity for students worldwide interested in Rust & compilers, who are likely reading Internals already. That is why I suggested this forum to @jamborm instead of Users.

9 Likes