Open
Description
This is pretty easy: we have a lot of FIXME
s 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 FIXME
s 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