We introduce a strict policy for C++ CTU. It can work across TUs only if
the C++ dialects are the same. We neither allow C vs C++ CTU. We do this
because the same constructs might be represented with different properties in
the corresponding AST nodes or even the nodes might be completely different (a
struct will be RecordDecl in C, but it will be a CXXRectordDecl in C++, thus it
may cause certain assertions during cast operations).
Details
Diff Detail
- Repository
- rC Clang
- Build Status
Buildable 25684 Build 25683: arc lint + arc unit
Event Timeline
Hi Gabor,
Please find my comments inline.
Hah. Do we support CTU for other languages, like ObjC and ObjC++? Can this be an issue there?
That's a good question. In Samsung, CTU hasn't been tested on ObjC code. Upstream CTU supports only FunctionDecls as well so its ObjC status is questionable..
lib/CrossTU/CrossTranslationUnit.cpp | ||
---|---|---|
31 | Why don't we place it into the anon namespace just below? | |
35 | This has to be split, probably with early returns. Example: if (Lhs.getArch() != Triple::UnknownArch && Rhs.getArch() != Triple::UnknownArch && Lhs.getArch() != Rhs.getArch() return false; ... | |
47 | We can use Triple::isOSUnknown() instead. | |
59 | // end namespace llvm is much more common. | |
203 | Reference char should stick to the variable, not to the type. | |
211 | Comments should end with a dot. Same below. | |
test/Analysis/ctu-unknown-parts-in-triples.cpp | ||
9 | Two spaces after ExprInspection. |
Hah. Do we support CTU for other languages, like ObjC and ObjC++? Can this be an issue there?
I really don't know. We never tried it, our focus is on C and C++ for now. Unfortunately, there is nobody with ObjC/C++ knowledge and (more importantly) with interest to try CTU and report any errors.
include/clang/Basic/DiagnosticCrossTUKinds.td | ||
---|---|---|
19 | I am not sure if we want this to be an error. The analysis could continue without any problems if we do not actually merge the two ASTs. So maybe having a warning only is better. My concern is that once we have this error, there would be no way to analyze mixed language (C/C++) projects cleanly using CTU. | |
lib/CrossTU/CrossTranslationUnit.cpp | ||
212 | I think we should not emit an error here. It should be up to the caller (the user of the library) to decide if she wants to handle this as an error, warnings, or just suppress these kinds of problems. I would rather extend emitCrossTUDiagnostics as a shorthand for the user if emitting an error is the desired behavior. |
include/clang/Basic/DiagnosticCrossTUKinds.td | ||
---|---|---|
19 | Okay, I agree, I changed it to be a warning by default. | |
lib/CrossTU/CrossTranslationUnit.cpp | ||
212 | I would prefer to exploit the capabilities of the DiagEngine, instead of extending the interface of CrossTranslationUnitContext. |
lib/CrossTU/CrossTranslationUnit.cpp | ||
---|---|---|
212 | You do not need the extend the interface. There is already a function for that below. Also, the user might not want to display a warning either but do something else, like generate a log message. |
lib/CrossTU/CrossTranslationUnit.cpp | ||
---|---|---|
212 | Ah, okay, I missed that. Now I added a case to that function. Still, I think having a DiagGroup is useful anyway. |
We should probably prefer %clang_analyze_cc1 to %clang_cc1 -analyze here too.
Ok, changed that.
FWIW, ASTUnit seems to save an effective triple while the current AST uses the nominal triple. (for example, armv7a-xx-xx-eabihf vs armv7a-xx-xx-eabi). I'm not sure if there is a good solution other than using heuristics to allow some differences.
I am not sure if we want this to be an error. The analysis could continue without any problems if we do not actually merge the two ASTs. So maybe having a warning only is better. My concern is that once we have this error, there would be no way to analyze mixed language (C/C++) projects cleanly using CTU.