Seems like an LLVM bump regression:

In file included from pinentrydialog.cpp:30:
In file included from ./pinentrydialog.h:29:
In file included from /nix/store/yywbwgbd1k3ld4lxwqhb3ib121zwyhxf-qtbase-5.12.10-dev/include/QtWidgets/QDialog:1:
In file included from /nix/store/yywbwgbd1k3ld4lxwqhb3ib121zwyhxf-qtbase-5.12.10-dev/include/QtWidgets/qdialog.h:43:
In file included from /nix/store/yywbwgbd1k3ld4lxwqhb3ib121zwyhxf-qtbase-5.12.10-dev/include/QtWidgets/qtwidgetsglobal.h:43:
In file included from /nix/store/yywbwgbd1k3ld4lxwqhb3ib121zwyhxf-qtbase-5.12.10-dev/include/QtGui/qtguiglobal.h:43:
In file included from /nix/store/yywbwgbd1k3ld4lxwqhb3ib121zwyhxf-qtbase-5.12.10-dev/include/QtCore/qglobal.h:45:
In file included from /nix/store/bb0bgspj580fghgzv9d9zvk5k9nn98d3-libcxx-11.1.0-dev/include/c++/v1/type_traits:417:
In file included from /nix/store/bb0bgspj580fghgzv9d9zvk5k9nn98d3-libcxx-11.1.0-dev/include/c++/v1/cstddef:37:
../version:1:1: error: expected unqualified-id
1.2.0-unknown
^

I've seen a similar issue pysathq/pysat#102 where #include <version> from inside libc++ is somehow picking up a header file from a build directory. Could be that some wrong -isystem is creeping into the build, but that would be a bug in our cc-wrapper.

cc @toonn

@veprbl, FWIW, AFAICT this is because many projects put the current directory, which is usually the root of the repo, in the include paths. And since these version files occur in many repos, it causes a problem.

IMO whoever figured this include was fine to put in the standard library, figured wrong. I haven't come up with a better fix than renaming the version files until upstream does so.

@toonn What you say makes sense. I wasn't expecting the libcxx system header to take priority.

Consider:

git checkout c1220ff9b0d8092564dee7ba083cfe2c572eed8e
nix-build -E '(import ./. {}).pinentry.overrideAttrs (prev: { NIX_DEBUG=1; })'

The last command will look like

So, according to https://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html, the -I. would take precedence over -isystem /nix/store/bb0bgspj580fghgzv9d9zvk5k9nn98d3-libcxx-11.1.0-dev/include/c++/v1.

IMO whoever figured this include was fine to put in the standard library, figured wrong. I haven't come up with a better fix than renaming the version files until upstream does so.

What if we patch the libc++ itself to use full paths in the include directives? There are a few locations like

sed -ne '37p' /nix/store/bb0bgspj580fghgzv9d9zvk5k9nn98d3-libcxx-11.1.0-dev/include/c++/v1/cstddef
#include <version>

No no, I'm saying the current directory indeed has precedence and therefore the stdlib tries to include a file containing just a version number.

That might be a good temporary workaround. Does mean the core of these issues will have one less motivating factor to get fixed but I guess that's upstream's responsibility.