Priorities below 101 are reserved for the implementation, so that's what
we should be using here. That is unfortunately only supported on more
recent versions of Clang. See https://reviews.llvm.org/D31413 for details.
Details
- Reviewers
aaron.ballman ldionne - Group Reviewers
Restricted Project - Commits
- rG7c49052b170f: [libc++] Use init_priority(100) when possible
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
libcxx/src/experimental/memory_resource.cpp | ||
---|---|---|
79 | @arthur.j.odwyer Pinging you here since you wrote that code. Does this LGTY? |
libcxx/src/experimental/memory_resource.cpp | ||
---|---|---|
79 | @ldionne: I just copied this line from experimental/... oh wait, this is experimental/... yeah, this was added by @EricWF in https://github.com/llvm/llvm-project/commit/4efaa30934e81 . IIUC, if we're sure this file is always compiled as C++14 at this point, then I don't even think it matters what we put here. In C++20 we should mark this variable constinit. However, whatever you decide on, it'd be useful if you could add a review comment to D89057 . |
CC @thakis
FYI, this change added an inconvenience in builds with clang-cl; the dummy preprocessor line directives (e.g. # 80 "iostream.cpp" 1 3) end up output as part of /showIncludes, which is what Ninja (and other tools) use for gathering info about the dependencies.
The command output contains this:
Note: including file: C:/<builddir>/include/c++/v1\__undef_macros [... more of the same ...] Note: including file: iostream.cpp
The dependency on iostream.cpp is a dummy (the input file isn't found). This causes ninja builds to always rebuild iostream.cpp every time ninja is invoked, even when nothing has been touched. Running with ninja -d explain prints:
ninja explain: output iostream.cpp of phony edge with no inputs doesn't exist ninja explain: iostream.cpp is dirty ninja explain: src/CMakeFiles/cxx_shared.dir/iostream.cpp.obj is dirty
But I'm not sure if this is inconvenience enough to do something about it (I guess alternatives is to either use a windows specific mechanism directly, for setting a high enough priority for the constructors, or to just use the regular priority 101, so it doesn't need the dummy source markers).
FWIW, this workaround has always felt like a hack to me. Now that I think of it, perhaps we can push/pop the system header pragma around it instead?
@arthur.j.odwyer Pinging you here since you wrote that code. Does this LGTY?