Today work has focused on two things; Realizing the new MCP implementation I had started off on was not feasible, and rebasing/fixing a few PRs that had conflicts. I also started looking into another old issue in the 1.0 milestone.
Most of the day was spent further reading through the rustc codebase, trying to potentially understand the consequences of the changes to the allowed set of cfg values. After a few hours, I came to the realization this would need a separate RFC.
For the last two days, I’ve been blindly thinking that it would be just fine to extend the cfg system to allow for lower and upper bounds to be set on the values. This is very much possible, but it’s a non-trivial expansion to the cfg system.
So much so, that I eventually realized this would be touching upon the versioned cfgs RFC and the binary relations that would be introduced for “version” cfgs, which would fit the same less than or equal semantics I was trying to implement with the bounded expected values.
I pointed that out in the MCP PR thread, and dropped the relevant commits. I’ve also mentioned that maybe once that RFC lands, it’s more feasible to put up another RFC that extends that functionality to apply to specific cfg variants rather than whole cfg keys.
But, thinking twice about it, once that one RFC lands, it’s best if we focus on extending it to support target-specific versioning rather than attempting to adapt the functionality to existing cfgs. The current MCP is only a short-term solution, after all.
In then went on to review some PRs I had with pending merg conflicts. There was one in particular that took a while to solve.
After rebasing the patchset that submitted a complete definition for siginfo_t, some code that hadn’t turned up with conflicts introduced an item resolution error in Rust.
Simply reviewing the diffs didn’t reveal much context because the literal diff context window in git-log was not large enough for me to see the pulled, conflicting changes.
That took a while, but I’m positive it’s solved now. The last thing I got to do today was reading through an issue that discussed the glibc support policy in rust-lang/libc.
At present, I think this could be solved quite easily by incorporating a section to the recently added documentation on usage guidelines. But I’d have to look some more into it (possibly with fresher eyes.)
None.
The MCP implementation work should be virtually done. The extension that I had started to work on for the last three days has been abandoned. I highly doubt the changes required there would be possible without prior discussion.
Getting a temporary workaround only for OpenBSD systems neither seems like a viable option. I’ll keep working on rust-lang/libc issues then.