This is pretty easy: we have a lot of FIXMEs scattered throughout the codebase, and we want to be relatively certain that we don't miss anything important before the 1.0 release. We should try to classify any bare FIXMEs to make this easier. Suggested categories:
// FIXME(union): ...: something should be a union but is represented as a struct (will be fixed in 1.0), or a test that needs to be skipped because of it
// FIXME(musl): ...: something that should go away once we update our musl version
// FIXME(ctest): ...: something that doesn't work because of limitations of ctest its dependency garando_syntax
// FIXME(time): ...: something that needs to be adjusted relating to 64-bit time
// FIXME(linux), FIXME(macos), FIXME(netbsd), etc: something that will change when we update supported versions of a platform
// FIXME(1.0): ... anything else that needs to be addressed with a breaking change
This is pretty easy: we have a lot of
FIXMEs scattered throughout the codebase, and we want to be relatively certain that we don't miss anything important before the 1.0 release. We should try to classify any bareFIXMEs to make this easier. Suggested categories:// FIXME(union): ...: something should be a union but is represented as a struct (will be fixed in 1.0), or a test that needs to be skipped because of it// FIXME(musl): ...: something that should go away once we update our musl version// FIXME(ctest): ...: something that doesn't work because of limitations of ctest its dependencygarando_syntax// FIXME(time): ...: something that needs to be adjusted relating to 64-bit time// FIXME(linux),FIXME(macos),FIXME(netbsd), etc: something that will change when we update supported versions of a platform// FIXME(1.0): ...anything else that needs to be addressed with a breaking change