Precise macro value type

[dingxiangfei2009]

Fix #923.
Fix #3200. This is due to a fallout from how libclang type would be processed with this patch.

This patch introduce a new generator flag --macro-const-use-ctypes, which resolves the macro definition expression to a precise type advised by Clang if activated.

A macro expansion result adapter is introduced to maintain compatibility with cexpr, which has a limited capacity to resolve to a precise C type.

There is a change to the testing code because up to this point our tests, which can be executed concurrently, use the same path to the precomputed headers. Since this patch introduces a second test that relies on libclang macro fallback, the precompiled headers from the two different tests would overwrite each other. The new addition is that the backing files are now temporarily stored at different directories named after the header files under tests.

[dingxiangfei2009]

Apparently the clang fallback has race condition. If I set thread number to 1, we don't have truncated output anymore.

[dingxiangfei2009]

I have a theory about the test setup leading to the racing. The test setup uses the fallback translation unit backed by a file, which is located in ./.macro_eval.c by default. If the tests run concurrently, they are racing on this shared file. That probably explains why I get evaluation failure "randomly."

Update: yes, the two tests are racing on writing into the precompiled header.

[dingxiangfei2009]

r? @emilio

🙏

[emilio]

Looks good, some (optional) nits.

[dingxiangfei2009]

Are there any outstanding concerns about this PR?

[dingxiangfei2009]

The macosx test failed. Could it be that we need to reconstruct the builder, or at least update brew packages in the runner?

[dingxiangfei2009]

@emilio Shall we have a look at it again?