Today work has focused on four things; Continuing work on the MCP implementation, adding a cfg to possibly top off the bulk of GSoC, reviewing the L4Re PR and reviewing my GSoC work prodcut.
I started off by adding support for a cfg that ensured all of the existing unstable cfgs we expose in rust-lang/libc can be easily toggled by downstream crate consumers. This was at the request of my mentor.
That was fairly simple, and it seems like it works (based off of running CI on the test suite.) Then I went back to looking into the MCP implementation, where I’ve started making changes to the check-cfg system.
Thus far, I’ve noticed that the type infrastructure revolving check-cfg and the types of values it recognizes is a bit lacking. The type in charge of keeping each individual set of accepted values is only capable of either accepting any value or specific values.
In this instance, I need check-cfg to include among the well-known values (i.e. target_env’s values) a number larger than or equal to some value in the cfg’s value. This is so that older Rust compilers don’t complain in code that uses newer OpenBSD versions in target_env.
This has thus far meant adding a new variant to the type as well as some utilities to both produce a decimal representation of the target_env value and to keep that as an interned integer in the map of well-known values.
I then went on to look through rustc_interface, which is the only crate that makes use of the routine setting the afore-mentioned well-known values. That’s where I left if off today.
Then I reviewed the L4Re PR as the target maintainer answered back approving of my adding the flock and flock64 records. These aren’t part of upstream l4re-core, but they mentioned these interfaces will be included in the future.
I also replaced most of the deprecation attributes with FIXME comments. Back when the PR was first opened, the plan was to deprecate and not to delay until 1.0, so that was pending.
The AIX PowerPC64 PR also got approval from the target maintainer to merge, though there seem to still be issues with some tests. We don’t test for AIX on CI, and the cfarm machines are too slow to test on them, so the target maintainer will take care of that in a follow-up.
Finally, today I reviewed the GSoC work product, and I think the first draft is officially ready to receive external feedback.
None.
The MCP implementation plan will, as expected, take two more days. That will be the minimum time required until I can wrap my head around the logic in the rustc_interface crate, which seems to be the entry point after rustc_driver.
From the run_compiler function on, I’ll keep looking into places where the CheckCfg type is used, and see into changing the check logic to take into account this new lower bound type of limit.
The GSoC work product is ready, and I have no pending PRs on my end, so hopefully I can dedicate myself in full to the MCP implementation efforts.