Do not disable GNU extensions when building grammars #8953
Conversation
Commit ca65d31 ("always build grammars with c++14 and c11 (helix-editor#6792)") turned on semi-strict standard mode for C and C++ by accident. Some grammars use non-standard functions such as isascii (from <ctype.h>) and fail to build as a result, particularly with future compilers which do not support implicit function declarations. (Ideally, the build environment would only raise the standard versions relative to the toolchain default, not lower them, but this change does not implement that.)
the-mikedavis
added
A-tree-sitter
|
I would rather see this fixed on the grammar side. Especially because we want grammars to build on windows too where gnu extensions are not available anyway. In this case there also seems to be a Microsoft specific isascii function but I am not actually sure it's equivalent. Defining isascii is pretty trivial (it's even a macro on windows) so I would rather go that route |
It is equivalent: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/isascii-isascii-iswascii?view=msvc-170 The current switch disables the extensions on GNU/Linux, but not on Windows, and probably not on the BSDs, either. |
|
sure but those are non-standard microsoft extensions. In this case its not a huge issue but there are many gnu extensions without equivalents on windows (and the reverse) or functions that work subtely differently. The function in question is even deprecated so its probably a good idea to move away from using it regardless. Grammars should not be relying on non-standard C extensions that will just lead to portability issues. |
|
Closing as #9021 was merged which addresses the treesitter-d issue. Upstream made the same call as we did here: We should not be using POSIX/GNU extensions as that is not portable: |
Commit ca65d31 ("always build grammars with c++14 and c11 (#6792)") turned on semi-strict standard mode for C and C++ by accident. Some grammars use non-standard functions such as isascii (from <ctype.h>) and fail to build as a result, particularly with future compilers which do not support implicit function declarations.
(Ideally, the build environment would only raise the standard versions relative to the toolchain default, not lower them, but this change does not implement that.)
Related to: