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:

// A very specific set of circumstances (mainly, implementing Deref, and having a procedural macro and a Debug derivation in external crates) caused an internal compiler error (ICE) when trying to use rustdoc. This test reproduces the exact circumstances which caused the bug and checks that it does not happen again.

Source

One gets dizzy imagining the contributors back then, like masterful chemists, isolating and purifying the united causes of this obscure error, until at last illumination strikes, resulting in the deletion of a single line of code, and the creation of a run-make test easily 10 times larger than the fix itself.

This week, running through review comments and implementing requested suggestions and patches proved steady and rhythmic. Another fresh batch was on its way to getting shipped to the Rust compiler - packaged, wrapped up, with a nice r+ sticker on it. We just needed a quick test on the Microsoft Visual C++ compiler for compatibility...

Which caused the Bors bot to go rogue and... seemingly try to merge without running the compatibility test. I mean, really now? The bot's profile picture on Github is literally HAL 9000's eye. What could possibly go wrong giving the bot managing a programming language designed for robustness (excellent for tasks critical to humanity, such as space exploration, the creation of drones to save orphans from blazing buildings, and the blockchain generation for non-fungible tokens) the physical appearance of a fictional robot not known for its valuing of human life?

The runaway machine was subdued, and the pull request is safe... for now.

Merged this week

• no-intermediate-extras
• reset-codegen-1
• external-crate-panic-handle-no-lint
• noalias-freeze
• core-no-oom-handling, non-pie-thread-local, deref-impl-rustdoc-ice (I am bundling these up in the same pull request now, as the frontpage spam was getting a little intense, which was noticed.)

Open

• pgo-branch-weights, where a peculiar error happened on aarch64 about failure to create a profdata file. I'll go over this in my weekly check-in meeting tomorrow.
• emit, mixing-formats, bare-outfile, where the bot went rogue. A strange error still remains - as I am typing this, the test is being restarted.
• link-arg, link-dedup, no-panic-blank-output, which should probably be UI tests instead?

Oxidizing My Toolkit

So, I've been a VSCodium (the no-telemetry version of VSCode) plebeian for a long time, but my techiest friend insisted on how COOL and PRODUCTIVE it is to have a modal editor. But not ANY modal editor. It had to be Helix. Which is like Neovim, but written in Rust (this is the only argument I needed to be convinced).

I also found for myself a terminal multiplexer, Zellij, which is like Tmux but written in Rust (this is also the only argument I needed to be convinced).

Before someone posts me on r/programmingcirclejerk, I am jesting and I found myself enjoying Helix not because of "blazing speed" or any other crab-related meme, but really just because:

• It shows me a lot of keybinds when I press space or g, and what they do
• It doesn't require me to install any extensions

I quickly learned the basics - i to insert, e and b to move through words, I and A to move to the start and end of a line, and most amusingly, pressing C to duplicate my cursor. I always feel like a masterful illusionist when doing it.

I am actually typing this on Helix right now. And yes, I just suddenly felt the need to uselessly summon a bunch of clones of myself because it's just so cool. I am actually typing this on Helix right now. And yes, I just suddenly felt the need to uselessly summon a bunch of clones of myself because it's just so cool. I am actually typing this on Helix right now. And yes, I just suddenly felt the need to uselessly summon a bunch of clones of myself because it's just so cool. I am actually typing this on Helix right now. And yes, I just suddenly felt the need to uselessly summon a bunch of clones of myself because it's just so cool. I am actually typing this on Helix right now. And yes, I just suddenly felt the need to uselessly summon a bunch of clones of myself because it's just so cool. I am actually typing this on Helix right now. And yes, I just suddenly felt the need to uselessly summon a bunch of clones of myself because it's just so cool. I am actually typing this on Helix right now. And yes, I just suddenly felt the need to uselessly summon a bunch of clones of myself because it's just so cool. I am actually typing this on Helix right now. And yes, I just suddenly felt the need to uselessly summon a bunch of clones of myself because it's just so cool. I am actually typing this on Helix right now. And yes, I just suddenly felt the need to uselessly summon a bunch of clones of myself because it's just so cool.

After just one week, I really do feel more productive in it than I was in VSCodium. I think the most useful part is easily the file picker, as it gives previews of each file while browsing, unlike VSCodium's Ctrl-P. It's great for run-make tests, as I simply write "Makefile" and start browsing tests quickly and isolating which ones are doable with the current state of the support library with little effort.

Another neat touch to make programming even more fun :3