Today work has focused on finishing up the reviews I had left on rust-lang/libc and on continuing work on the compiler (which has unfortunately not met today’s goals.)
The review work was fairly simple to go through. The one PR that I left unfinished yesterday was the one that completed the definition of siginfo_t in Linux targets, and moved the whole shebang over to the new module tree.
Most of the changes consisted of adapting some architecture-specific stuff I missed from upstream’s overrides, and on cleaning up the use of multiple modules I was making to centralize it all under one module.
The latter task sort of defeats the purpose of the new module tree, where we try to map the tree structure as closely as possible to upstream, but the other way around it was neither quite as close to what they’ve got set up in glibc, and it was a lot more verbose.
Then I also made some tweaks to the reexports, so as to ensure they don’t expose module paths that in C you would get a compile-time error for through the #pragmas that glibc has set up in their internal header files.
The Android PR that backported the soundness issue to the next 0.2 stable release has been merged.
Then I also got to touch up the PR that added support for a manual non-exhaustiveness implementation on all the records we declare within our MBEs. This one only needed me dropping the commits in the PR patch, and cherry picking those from the alternative patch I built yesterday using another PR’s patchset as base.
The time64 cfg PR only needed some small fixes to improve future maintenability. The PR that refactored public padding fields into using our dedicated type is also ready, and only needed me rebasing and solving conflicts against main. This one is the one that won’t be backported (unlike the patchset that got merged yesterday.)
I also started looking into extending ctest to allow testing only specific module paths from a given crate. I already commented on this having popped up while working on the netlink PR yesterday or the day before, and now that I’m done with PRs, I’ve opened a tracking issue.
In terms of compiler work, today has been a slow day, but one in which I’ve learnt quite a few things about the flexibility of OCaml’s module system. Yesterday, I had implemented this extensible generalized algebraic data type that I used as a form of promise for certain expressions about the types of expressions that their data constructor arguments could yield.
This I thought I could easily figure out this morning as yesterday I had stumbled upon some issues while testing it out. Apparently, unlike the Rust trait system, OCaml need not have a specific type class tied with a module in an applicative functor whose parameter is constrained by a module signature.
This means you can have a module functor know about its parameter’s signature without enforcing the same visibility on the parameter’s interface as an invidual module outside the namespace of the functor’s module expression. This in turn means that you can have any module fed into the functor, so long as recovering the module type of that module expression yields a module signature compatible with that of the functor’s parameter.
What I failed to realize for a few hours was that the module signature of the functor’s parameter need not be used in both the functor and the modules that will be fed into the functor. I struggled quite badly trying to bend the type system into my will by having some fairly crazy type equations on the single type that the module type defined.
At the end of the day, I only had to get rid of the module signature constraint while defining the module implementations that got fed into the functor, and that did the trick. Reading over and over through the OCaml manual helped.
None.
I expect to possibly spend more than a week working on extending ctest. I have a rough idea of how I would do it, as I know some of its implementation details but have never had the chance to fix a bug in it nor implement a feature. The plan is to look into the parsing logic, and implement an extension interface that recursively selects among the parsed items a set of modules. If such an attempt yields a module compatible with the provided module path in the call to ctest::generate_test, then we’re gold. Then we’ll start worrying about how much of the askama test templates i have to adapt (let us hope none.)
The compiler work expected me to finish the operator work today. That has been met with failure, but the stuff that I got done today was a pre-requisite to the operator work. Now that the yielder type is working, I can more ergonomically constrain the data constructor parameter types to the concrete expressions I know can be used as operands.