@jethrogb Hi, I’m so glad you are interested, and I’m sorry for not following up sooner. I don’t think there are any obstacles to proceeding, as refactoring in this direction seems fairly unobjectionable.
There are a few ways to proceed, but I think getting to the point where you can implement a custom std out of tree will be a long road.
For refactoring std, the easiest thing to get started is by cutting down entries in the tidy whitelist, where std is not using conditions in the right modules. These are easy patches to make and review.
Someone could also be bold and create the pal_common / pal_unix / pal_windows crates and wire them up to the build system. I suspect that would get past review with some debate. After that there will be a long slog of puzzling out how to pull pieces out. I mentioned some other next steps in my op. And remember my linked branch has uncommitted refactoring steps that, while bitrotted, demonstrate some sequences that work to untangle dependencies.
As far as your end goal of creating a std port that excludes large
chunks of std, for now I would focus on creating a port that fits into
the model described here, where the customization is at the sys/pal
layer. Today, I would suggest that, instead of trying to compile out
parts of std your port doesn’t use, settle for panicking instead. In
the longer term, when std has scenarios, then we can actually remove
the unsupported features. This might involve a custom platform
under the libstd/sys directory, and ultimately a custom pal crate.