Is this observable from a clang command line tool? Be nice to have a lit test.

Avoid passing a new IgnoringDiagConsumer for the test since it's unused.

Thank you for the fix! 🙇🏻‍♂️

In D143981#4125246, @jbms wrote:

The MSVC ".asm" files aren't preprocessed, though.

.s files can use the preprocessor as well. I'd recommend to add a file that do the renames using #define, like in blake3_impl.h, and include it in all the .s files.
That way the changes to the original files is minimized, which is useful for pulling in future changes from the original repo.

In D143612#4114178, @benlangmuir wrote:

I think we should verify the performance impact to running tests is minimal before landing this, like they did with the _GLIBCXX_ASSERTIONS change.

In D141910#4112144, @domada wrote:

@akyrtzi Thank you for your feedback. Can I land the patch?

In D141910#4111048, @domada wrote:

Added changes in clang/lib/AST/CMakeLists.txt to address build issue reported by @akyrtzi .

I modified CMakeLists.txt so that it requires generation of missing Attributes.inc.

@akyrtzi Please let me know if it solves your issue

In D143461#4110405, @benlangmuir wrote:

Dupe of https://reviews.llvm.org/D143428 ?

would be great to test it more in a semantic way if possible

I've reverted this change from main branch, let me know if there's anything I can do to help with addressing the build issue.

Hi @domada, these changes break compilation of clang, with such build error:

FAILED: tools/clang/lib/AST/CMakeFiles/obj.clangAST.dir/ASTContext.cpp.o 
<clang invocation>
In file included from /llvm-project/clang/lib/AST/ASTContext.cpp:81:
In file included from /llvm-project/llvm/include/llvm/Frontend/OpenMP/OMPIRBuilder.h:17:
In file included from /llvm-project/llvm/include/llvm/Analysis/MemorySSAUpdater.h:37:
In file included from /llvm-project/llvm/include/llvm/Analysis/MemorySSA.h:93:
In file included from /llvm-project/llvm/include/llvm/Analysis/AliasAnalysis.h:44:
In file included from /llvm-project/llvm/include/llvm/IR/PassManager.h:45:
In file included from /llvm-project/llvm/include/llvm/IR/Function.h:25:
In file included from /llvm-project/llvm/include/llvm/IR/Argument.h:17:
/llvm-project/llvm/include/llvm/IR/Attributes.h:90:14: fatal error: 'llvm/IR/Attributes.inc' file not found

Reproduction steps:

Add test case for dependency directive lexing of ill-formed include inside __has_include

This is useful for functionality, like in an IDE, to show the top headers of a module import for navigational purposes.
Is it reasonable to at least have an alternative implementation for it (e.g. from the module headers find the headers that were not included from other headers), not sure if it'd be straightforward or not.

Yeah, you mainly need more than 32 decls to exceed the small storage of Scope::DeclSetTy.

Is it impractical to add a test for this? Otherwise LGTM.

Committed, thank you for the quick fix! 🙇🏻‍♂️

Change LGTM, could you get this in soon? 🙏

Hi @IBricchi, the compiler error is still occurring (as of 1a9dec0dda0064cd0035d70b6534a65856b7a212).
To reproduce create a clean build directory (configure using ninja) and run ninja unittests/Analysis/CMakeFiles/InlineAdvisorPlugin.dir/InlineAdvisorPlugin.cpp.o.

Adjust code comment.

I prefer my original version because:

• eSymbolContextLastItem is not an appropriate name for collection of bits, it should be named like eSymbolContextReallyEverything or something, which then makes things a bit confusing due to having multiple "everything" enums.
• I like the code consistency and readability of all RESOLVED_* macros here being shifts by one of the previous bit. When I first read this code I had to stop and think about why RESOLVED_FRAME_CODE_ADDR is different than the rest; "eSymbolContextLastItem << 1" is clearer to understand IMO, particularly in the context of the other macros.

In D139066#3964435, @akyrtzi wrote:

In D139066#3964353, @jasonmolenda wrote:

FWIW I think the only change needed to the original patch is to keep using #define RESOLVED_FRAME_CODE_ADDR (uint32_t(eSymbolContextEverything + 1)) but switch to the new eSymbolContextLastItem that is defined. Possibly the comment about what this code is doing could be made a little clearer, because it is definitely not. :)

Thank you for the feedback, but it's unclear to me what you mean, are you saying leave the #define RESOLVED_FRAME_CODE_ADDR line unmodified? If yes, what does "switch to the new eSymbolContextLastItem" mean?

In D139066#3964353, @jasonmolenda wrote:

FWIW I think the only change needed to the original patch is to keep using #define RESOLVED_FRAME_CODE_ADDR (uint32_t(eSymbolContextEverything + 1)) but switch to the new eSymbolContextLastItem that is defined. Possibly the comment about what this code is doing could be made a little clearer, because it is definitely not. :)

In D137101#3897273, @rnk wrote:

@akyrtzi , FYI, thanks again for adding blake3 support.

Fix the patch.

ProvenanceAnalysis::relatedPHI: Return true only if both comparePHISources() calls return true

@nikic, it seems to have recovered (http://llvm-compile-time-tracker.com/compare.php?from=c49cde6467f9bf200640db763152a9dc7f009520&to=0456acbfb942f127359a8defd1b4f1f44420df3e&stat=instructions) let me know if you have concerns.