Good day. I'm your average every-day top-notch valedictorian. 5.00 GPA, aced the MCAT, cracked the GSoC, licensed pilot, certified ski instructor. You may also know me under one of my aliases: Neil Armstrong, Alan Turing, Stephen Hawking, Rosalind Franklin or Laika the Soviet Space Dog. Pleased to make your acquaintance.

The Great Ping Storm

Getting into the Google Summer of Code was quite the adventure. I had no idea this program existed until I saw the Rust blog announcement on it. Stellar! A way for me to tangibly thank the Rust community for how crucial their tool was to lighting the flame of my interest in computer programming!

Preparing my proposal and application drew me into a vortex of competitiveness and guides on how to "crack GSoC"... It made it sound like this ruthless, brutal filter exam where thousands of students are bundled up in a gigantic atrium and assigned a piece of paper that will determine their value as a human being depending on how the graphite marks on it are placed. It even has a really scary acronym to go with it!

I learned about the outcry related to various "open source initiation programs", such as Hacktoberfest, and how that one is a "corporate-sponsored distributed denial of service attack against the open source maintainer community.".

How intimidating! How to avoid being a "clueless, annoying n00b" when I am easily at least 2 out of those 3 qualifiers? The allegations of aforementioned cluelessness were certainly not challenged when a few careless clicks resulted in dialing a sizable portion of the Rust squad to my location. My assigned mentor later linked me to a discussion from February where some experienced Rust contributors were prophesizing the exact pitfall I ended up falling into.

imo it can also be kinda scary for newbies when you accidentally mess up your rebase, which triggers a ton of "files changed" and then bors notifies 20 people "please look at this"

For any wayward souls reading this, here is what happened precisely:

  1. Press the big green button on GitHub "sync with the master branch" on your forked repository. Your remote repository is now up-to-date, but your local repository on your computer isn't.
  2. Cluelessly make some changes, then force push to the remote.
  3. This undoes all the commits separating your remote and your local repositories, changing thousands of lines of code, pinging 20+ people and making the unfortunate n00b feel very flustered.

How to fix it: simply enter git pull upstream master --ff-only in Step 1 so your local repository stays up to date.

Makefile Recipes to Make Spaghetti

I was not expecting to get in! Yes, I am truly interested by the opportunity, and yes, I really, really like Rust. But the project itself didn't seem so... glamorous? Some other accepted GSoC contributors are doing such awesome wizardry! Especially this one! If I understand correctly, this would open up so many opportunities, such as convincing your boss, who is relying on a multi-decade old .NET codebase, that yes, they should be giving you the green light to start writing Rust on the job, that yes, your coworkers and future hires will learn this new programming language quickly and easily, and that yes, you are a reasonable employee who totally doesn't have an utterly unrealistic conception of team software development.

Jokes aside, for the eternally on-hiatus hobbyist gamedev dreamers out there, it could, to quote the author, "potentially, far off in the future, write Unity games with Rust".

Meanwhile, I am rewriting tests that already work. A gigantic (349 directories) suite of Makefiles running scripts to check the Rust compiler's stability throughout the many pull requests and changes added over the years. They "simply" need to be translated into Rust files. Petty intern work, surely!

Not completely. Allow me to extract some of the writing done in my proposal to demonstrate... Here isbranch-protection-check-IBT:

all:
ifeq ($(filter x86,$(LLVM_COMPONENTS)),x86_64)
$(RUSTC) --target x86_64-unknown-linux-gnu -Z cf-protection=branch -L$(TMPDIR) -C
link-args='-nostartfiles' -C save-temps ./main.rs -o $(TMPDIR)/rsmain
readelf -nW $(TMPDIR)/rsmain | $(CGREP) -e ".note.gnu.property"
endif

Did you get all that? This test comes with no comment on its function beyond “Check for GNU Property Note”. From what I understand, it conditionally compiles a Rust program for the x86_64 architecture with specific compiler and linker options, and then inspects the compiled binary to check for the presence of GNU-specific properties… Imagine being a contributor running into this test failing, and now needing to trudge through ancient documentation to understand what is happening here.

Information on what these tests actually do is sparse and not very informative. Test names are full of acronyms and only occasionally possess explanatory comments. Some of these tests also stretch out into the dozens of lines, only returning a generic statement of failure when an error is encountered and not indicating to contributors what caused the error.

There are also inconsistencies and unexpected behaviours, where oddities of the Windows operating system are accounted for using rough hacks and workarounds… And without Rust’s robust type checking and error handling, any of these tests could very well assume everything is fine when things actually are not.

Take for example this const-prop-lint test, designed to verify that there are no object (.o) files left behind after the compilation, which could happen if the code generation process was interrupted due to an arithmetic overflow error.

all:
$(RUSTC) input.rs; test $$? -eq 1
ls *.o; test $$? -ne 0

Imagine a case where buggy code generation fails to create any files no matter what - this test will naturally pass, as it considers “no output at all” to be just as fine as “no .o files detected”. Not to mention cases where “ls” could behave strangely with potential special characters...

Here is another example. This test is composed of only four lines of code - a job easily done, surely?

all:
$(RUSTC) --crate-type=staticlib nonclike.rs
$(CC) test.c $(call STATICLIB,nonclike) $(call OUT_EXE,test) \
$(EXTRACFLAGS) $(EXTRACXXFLAGS)
$(call RUN,test)

Unfortunately, this test makes use of a static library file, which looks like libnonclike.a on Unix and nonclike.lib on Windows. My mentor utilized this function to take this into account.

if target().contains("msvc") {
	format!("{name}.lib");
} else {
	format!("lib{name}.a");
}

Jieyou Xu, the mentor for this project, has already written a minimalist version of the tool that will let the Rust codebase swap these tests into rmake.rs files written in pure Rust. It can handle basic and most common Makefile functions, like passing arguments around and specifying compilation targets. Features beyond this barebones functionality are progressively being implemented, such as the diff Bash utility in this recent pull request.

Dust Swept Under The Rug

For these reasons, this task has basically remained in the realm of "annoying enough to be important to fix, but not critical enough for the job to actually get done" since... 2017.

The next steps:

  • Browsing through the test directory, and understanding what each test actually does, or if it actually does anything at all. Some archaeology required. Certain tests are poetically named issue12345 to track specifically a certain GitHub issue, but that is only the case of a small minority...
  • I am thinking it may be interesting to write a quick script to go through all tests in the directory and annotate which ones are reliant on which Bash utility. For example, since diff is already implemented and grep is quite easy to implement, all tests that use these utilities only could be the first targets for working.
    • This could be put inside a .csv file for easy central access and organization.
  • Connecting to and using Remote Dev Desktops, which have been graciously offered to me after I revealed the glorified high school calculator that serves as my computer took multiple long minutes to build the Rust compiler locally.
  • Establishing priorities, expectations and goals. Unexpectedly, after my proposal submission, a company I had forgotten about called me back for a full-time internship over the summer. Harmonizing this with GSoC will be... a true challenge in self-organization. I plan to monitor myself very closely and take action if I sense I am overworking myself.

If you enjoyed this writeup, feel free to contact me!

  • Discord: oneirical
  • Reddit: https://old.reddit.com/user/oneirical/
  • Zulip: https://rust-lang.zulipchat.com/#user/693959
  • Email: julien-robert@videotron.ca