Said commit was meant to fix [Issue#64], but rather introduced new
problem -- when "decltype(nullptr)" was observed (happens on transitive
includes starting with standard C library headers, at least with newer
stdlibc++ as this is how includes are treated by gcc when it's passed
"-x c++-header"), the C-only-detection logic would short-circuit (or
give up) early, leaving C++ compatibility measures off, and in turn,
choking later on when valid C identifiers such as "new" are used
somewhere in the headers of the C project at hand.
This rather simplistic solution masks, item-wise, "decltype(nullptr)"
expression consisting of otherwise C++ compatibility mangling eligible
words, and restores them right after there's no danger this would happen
to them, because they need to be preserved (empirically tested).
Said commit was meant to fix [Issue#64], but rather introduced new problem -- when "decltype(nullptr)" was observed (happens on transitive includes starting with standard C library headers, at least with newer stdlibc++ as this is how includes are treated by gcc when it's passed "-x c++-header"), the C-only-detection logic would short-circuit (or give up) early, leaving C++ compatibility measures off, and in turn, choking later on when valid C identifiers such as "new" are used somewhere in the headers of the C project at hand.
This rather simplistic solution masks, item-wise, "decltype(nullptr)" expression consisting of otherwise C++ compatibility mangling eligible words, and restores them right after there's no danger this would happen to them, because they need to be preserved (empirically tested).
[Issue#64] https://github.com/lvc/abi-compliance-checker/issues/64