It would be awesome if the applicable parts of the STL were tested for use in the Windows kernel. The author of this issue (Ben Craig) has tinkered with such a thing in the past, and I'm willing to help. This could be considered preparatory work for https://wg21.link/p1642, but it has value even with the status quo of the standard.

Low level theory of operation for tests:

• Have a "regular" user mode executable that takes the name of a kernel binary on the command line. The user mode executable will load and run the test in that kernel binary.
• The kernel binary will have a non-main entry point, and it will call main like a not-special function
• assert isn't freestanding, so the test harness (and not the production code) will have it's own, non-conforming implementation of assert that logs to a global buffer and continues. This has worked out surprisingly well for me, though in the general case, you could obviously corrupt kernel mode. Assert messages are output to stderr, and still cause the user mode executable to return non-zero.
• Running the kernel mode tests requires administrator privileges
• As part of the machine setup, test signing needs to be enabled on the machine / VM under test, and a self-signed certificate needs to be installed.
• This will likely require using the lit "Executor" machinery from the libcxx test suites. That machinery allows running tests through emulators, or ssh, or, in this case, through a user mode executable.
• If a test messes up bad enough, it will crash / blue screen your machine. So test in user mode first.

Open questions:

• What cmake and/or lit invocations should users need to run to cause these tests to be run? I suspect that we shouldn't make this test mode be part of a "default" x64 run.
• Should there be a distinct cmake configuration for kernel mode?
• Is installing certificates and enabling test driver signing permissible on a continuous integration run?