Szelethus added a comment.
In D86135#2233611 <https://reviews.llvm.org/D86135#2233611>, @martong wrote:
>> The fundamental problem is, we simply can't ask Preprocessor what a macro
>> expands into without hacking really hard.
>
> Can you summarize what is the exact problem (or give a link to a discussion,
> etc)? Is it an architectural problem in Clang itself?
I phrased myself poorly. The Preprocessor can tell what a macro usage
immediately expands into (otherwise this project would have been practically
impossible to implement), what it struggles to get done is show what a macro
usage in the source code turns into in the preprocessed translation unit. As is
often the case, macros may be nested into one another:
#define MACRO2(ptr) ptr = 0
#define MACRO1(x) MACRO2(x)
int *a = get();
MACRO1(a); // Step 1. Expand MACRO1.
// a.) Retrieve the tokens defined for MACRO1.
// b.) Resolve parameter x to argument a.
// Step 2. Expand MACRO2...
*a = 5;
From this code snippet, should we be interested in what `MACRO1(a)` expands
into, `Preprocessor` can pretty much only deliver on point 1a.) with any
convenience. The problem here is that it was simply never engineered to be used
outside of the preprocessing stage, so much so, that by the time I worked on
this project about a decade after `Preprocessor`'s inception, I still had to
turn super trivial methods const. Other than that, the discussions I linked in
the summary is pretty much all I can offer.
> Could we somehow refactor Clang and the Preprocessor to be usable for us? I
> mean LLVM and Clang has the mindset to build reusable components, the
> Preprocessor (and the Sema) should be one of them too, not just the AST.
Working with the `Preprocessor` seems incredibly tedious and error prone --
mind that this is almost literally the first thing we implemented in Clang, and
you can tell. Also, its performance critical, and any meaningful performance
impact may need strong justification. While it would be beneficial to have the
knowledge I'm crafting being integrated into the actual class, its hard to
justify all the effort it would take to do so, especially now this project is
so far along anyways. If I has to start from scratch, I would try to explore
other approaches, but might still end up just doing what I did here.
In D86135#2233695 <https://reviews.llvm.org/D86135#2233695>, @xazax.hun wrote:
> Is this related to https://bugs.llvm.org/show_bug.cgi?id=44493?
To some extent, but this patch unfortunately doesn't solve that bug. The
problem I think is that named variadic macros aren't supported at all.
================
Comment at: clang/lib/StaticAnalyzer/Core/PlistDiagnostics.cpp:910
+
+ void injextRange(const ArgTokensTy &Range) {
+ TokenRange = Range;
----------------
martong wrote:
> typo? `injectRange` ?
Yep.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D86135/new/
https://reviews.llvm.org/D86135
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
