Merged This Week

• suspicious-library, resolve-rename and incr-prev-body-beyond-eof

Opened This Week

• short-ice, which should be pretty much ready to wrap up and ship.
• link-args-order, ls-metadata and lto-readonly-lib, which has a very strange error where it crushes the entire wall of text that is stderr into nothing else but a single double-quote ".
• compiler-lookup-paths, dump-mono-stats and prune-link-args, which makes me run into the exact same issue the test author did 11 years ago - the ui test directory not understanding what a double-quote is.

Still Open

• pgo-branch-weights, which has now been open for 25 days. At least, with this big rebase on top of the new API, maybe something will actually happen for once.
• nm implementation, which has been completely reworked to use the object crate instead... and is now crushing me under a truckload of lifetime errors. There must be a better way to do this.
• fs wrappers, which only need to wait for the intimidatingly-named drop bombs to exit the merge queue.
• symlinked-extern, symlinked-rlib and symlinked-libraries, which simply needs fs wrappers merged before it can proceed.
• link-arg, link-dedup and clear-error-blank-output, which hilariously previously failed because the final test was previously named no-panic-blank-output, and it includes output.assert_stderr_not_contains("panic"), which was tripped by the name of the test. Right now, the test is failing because I am fighting the borrow checker for the last 2 statements:

out.assert_stdout_contains("lfoo");
out.assert_stdout_contains("lbar");

And it feels wrong to just derive(Clone) and call it a day.

The set of PRs merged and open this week is less bountiful this time - yes, I spent a lot of time debugging and patching some of the cursed tests clogging up the queue, but there has also been some interesting discussions and progress on improvements to run_make_support: tightening up the various utilities like rustc so their output must be handled, and making said output be much more controlled with designated functions to process stdout and stderr.

I've noticed that there's been some interest from experienced contributors in helping out the run-make-support efforts. In a way, I am glad - it shows that maintainers think this project has value and that it's not some "intern oubliette" where you assign beginners to an insignificant part of the codebase and breathe a sigh of relief as you realize there is no way they will break anything important.

But, it also makes it really motivating to do more, seeing all these metaphorical pickaxes striking the rock in unison, and mine not being as used as it could be. Don't get me wrong, the team seems happy with my progress thus far - a sustainable pace to match the extended 18 weeks duration - but had I not balanced this commitment with a full time internship, there could have been a little more pep to it.

Example: other Summer of Code contributors are relentlessly posting about what they do on their side in the Zulip thread, and I harbour some curiosity to understand more what they are doing - as just reading the words quickly without research is roughly equivalent to reading ancient Babylonian scripture. But, I am so drenched in technology weekly that it wouldn't be a good idea. I could, but I'm doing everything to keep the torch burning and try not to go to too many "extra miles" until I fall off the cliff.

My fear was making the foolish choice of mediocrity in two commitments over excellence in one. And, it doesn't seem like that is currently happening, but it is nonetheless worrying.

Once this summer passes, I will definitely be thinking things over more in the future when it comes to opportunities. Life isn't some RPG where you can have 12 active quests at the same time. I wonder how the highest octane maintainers do it, since they might be even busier than I am.

It's official - this week, 25% of all run-make tests are now successfully ported. Not exactly the most robust metric, considering certain tests are trivial and completed with a flick of the hand, while others make use of dark arcane secrets beyond the comprehension of any soul wishing to keep its sanity intact.

It's really satisfying how all I must do to search for new tests is searching "Makefile" in my text editor - as these run-make tests really are the last remaining traces of this cursed file format.

The infection might be beyond saving at my internship workplace (it is a tentacular, multi-decade-old C++ giga-codebase with tons of dependencies scattered across directories with cp commands in Makefiles to move them across the place). Basically the technological rendition of an ancient kraken with its circulatory system made out of cursed Bash syntax.

But, at least, the One True Programming Language is on a rightful path of healing.

Merged this week

• lto-smoke, simple-rlib, mixing-deps
• fpic, simple-dylib, proc-macro-init-order

Previously Open

• pgo-branch-weights - I found a rather glaring mistake where the input and output functions had their function bodies swapped. However, after fixing this, there is still a test failure on aarch64... with no error message beyond "has been running for too long". Fun. Did I... put some infinite loop somewhere??
• emit, mixing-formats, bare-outfile - Windows OS thinks it can be a special snowflake and have its own file permission rules. A fix was pushed by courtesy of my mentor, which should patch this pesky test once and for all.
• link-arg, link-dedup, no-panic-blank-output - frozen down by the fact that they need to be converted to UI tests with .stderr files, but I haven't managed yet to print the exact error message that should be received. Not that I spent much time on this one.

Newly Open

• symlinked-extern, symlinked-rlib, symlinked-library - was approved, then failed the basic CI over 10 times. The current error mentions something about being incapable of finding an external crate.
• suspicious-library, resolve-rename, incr-prev-body-beyond-eof - was in the merge queue, then failed the armhf-gnu test for an obscure reason linked to a object file "not in the right format".
• Helper functions for tmp_dir().join() and filesystem operations - simply needs a couple patches to pass the CI.
• Implementation of nm utility and bin-emit-no-symbols test - I tried my hand at making something with the Goblin crate, which is not currently allow-listed in the Rust repository. I will likely need to try an implementation based on the object crate instead.

Working a very "traditional" software engineering programming (I can't call myself an engineer, it's a legally protected title in my country) in conjunction with the Google Summer of Code is making me realize a really relevant dichotomy - the concept of who imposes the working schedule.

There is a huge appeal when it comes to choosing one's own schedule. I am given a contract with an expected result, and I just need to go for it, when it seems most right, sprinting intensely one day and taking the next one off. I don't need to carefully log in a virtual notebook how many hours it will take, how many I have used up, and be accountable for what I did day to day (only on a weekly basis).

I know there is a canyon of difference between these two worlds, but I feel really trusted with this latter system. The rigid, 9-to-5 planning stucture feels less like organization and more like supervision after this one-month compare-and-contrast endeavour.

That trust, I find, makes the work so much more enjoyable, because it makes me feel confident that I really can do this. I would be getting caged down much more if there were doubts!

It's a really great thing to realize now, because I am learning what I want - and what I do not want - from the years of life to come in my path.

Having these two commitments at the same time is tough, but I'd take the same decision all over again, as the juxtaposition truly is enlightening. My GSoC project has been extended to 18 weeks, so I can focus on keeping the medium and steady pace I have cultivated so far, and still enjoy the wonderful spring and summer days outside. c: