Commit Graph

35 Commits

Author SHA1 Message Date
Ilya Biryukov 4b03364d72 [AST] Traverse attributes inside DEF_TRAVERSE_DECL macro
Summary:
Instead of traversing inside the TraverseDecl() function.
Previously the attributes were traversed after Travese(Some)Decl
returns.

Logically attributes are properties of particular Decls and should be
traversed alongside other "child" nodes.

None of the tests relied on this behavior, hopefully this is an indication
that the change is relatively safe.

This change started with a discussion on cfe-dev, for details see:
https://lists.llvm.org/pipermail/cfe-dev/2019-July/062899.html

Reviewers: rsmith, gribozavr

Reviewed By: gribozavr

Subscribers: mgorny, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D64907

llvm-svn: 368052
2019-08-06 15:46:12 +00:00
Tom Stellard 2e97d2aa1b cmake: Add CLANG_LINK_CLANG_DYLIB option
Summary:
Setting CLANG_LINK_CLANG_DYLIB=ON causes clang tools to link against
libclang_shared.so instead of the individual component libraries.

Reviewers: mgorny, beanz, smeenai, phosek, sylvestre.ledru

Subscribers: arphaman, cfe-commits, llvm-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D63503

llvm-svn: 365092
2019-07-03 22:45:55 +00:00
Stephen Kelly ad3314b146 Add a Visit overload for DynTypedNode to ASTNodeTraverser
Reviewers: aaron.ballman

Subscribers: cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D61834

llvm-svn: 361117
2019-05-19 13:03:48 +00:00
Nico Weber e78ac9cc72 Revert r361033 "Add a Visit overload for DynTypedNode to ASTNodeTraverser"
It fails to build on some bots.

Also revert follow-up r361055.

llvm-svn: 361059
2019-05-17 18:31:24 +00:00
Stephen Kelly 0855896c68 Add a Visit overload for DynTypedNode to ASTNodeTraverser
Reviewers: aaron.ballman

Subscribers: cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D61834

llvm-svn: 361033
2019-05-17 13:55:28 +00:00
Gabor Marton 3c72fe1bad [ASTImporter] Separate unittest files
Summary:
Move generic redecl chain tests and visibility tests into their own
separate test files.

Reviewers: a_sidorin, a.sidorin, shafik

Subscribers: mgorny, rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D61786

llvm-svn: 360572
2019-05-13 10:06:25 +00:00
Roman Lebedev b570060fd8 [clang][OpeMP] Model OpenMP structured-block in AST (PR40563)
Summary:
https://www.openmp.org/wp-content/uploads/OpenMP-API-Specification-5.0.pdf, page 3:
```
structured block

For C/C++, an executable statement, possibly compound, with a single entry at the
top and a single exit at the bottom, or an OpenMP construct.

COMMENT: See Section 2.1 on page 38 for restrictions on structured
blocks.
```
```
2.1 Directive Format

Some executable directives include a structured block. A structured block:
• may contain infinite loops where the point of exit is never reached;
• may halt due to an IEEE exception;
• may contain calls to exit(), _Exit(), quick_exit(), abort() or functions with a
_Noreturn specifier (in C) or a noreturn attribute (in C/C++);
• may be an expression statement, iteration statement, selection statement, or try block, provided
that the corresponding compound statement obtained by enclosing it in { and } would be a
structured block; and

Restrictions
Restrictions to structured blocks are as follows:
• Entry to a structured block must not be the result of a branch.
• The point of exit cannot be a branch out of the structured block.
C / C++
• The point of entry to a structured block must not be a call to setjmp().
• longjmp() and throw() must not violate the entry/exit criteria.
```

Of particular note here is the fact that OpenMP structured blocks are as-if `noexcept`,
in the same sense as with the normal `noexcept` functions in C++.
I.e. if throw happens, and it attempts to travel out of the `noexcept` function
(here: out of the current structured-block), then the program terminates.

Now, one of course can say that since it is explicitly prohibited by the Specification,
then any and all programs that violate this Specification contain undefined behavior,
and are unspecified, and thus no one should care about them. Just don't write broken code /s

But i'm not sure this is a reasonable approach.
I have personally had oss-fuzz issues of this origin - exception thrown inside
of an OpenMP structured-block that is not caught, thus causing program termination.
This issue isn't all that hard to catch, it's not any particularly different from
diagnosing the same situation with the normal `noexcept` function.

Now, clang static analyzer does not presently model exceptions.
But clang-tidy has a simplisic [[ https://clang.llvm.org/extra/clang-tidy/checks/bugprone-exception-escape.html | bugprone-exception-escape ]] check,
and it is even refactored as a `ExceptionAnalyzer` class for reuse.
So it would be trivial to use that analyzer to check for
exceptions escaping out of OpenMP structured blocks. (D59466)

All that sounds too great to be true. Indeed, there is a caveat.
Presently, it's practically impossible to do. To check a OpenMP structured block
you need to somehow 'get' the OpenMP structured block, and you can't because
it's simply not modelled in AST. `CapturedStmt`/`CapturedDecl` is not it's representation.

Now, it is of course possible to write e.g. some AST matcher that would e.g.
match every OpenMP executable directive, and then return the whatever `Stmt` is
the structured block of said executable directive, if any.
But i said //practically//. This isn't practical for the following reasons:
1. This **will** bitrot. That matcher will need to be kept up-to-date,
   and refreshed with every new OpenMP spec version.
2. Every single piece of code that would want that knowledge would need to
   have such matcher. Well, okay, if it is an AST matcher, it could be shared.
   But then you still have `RecursiveASTVisitor` and friends.
   `2 > 1`, so now you have code duplication.

So it would be reasonable (and is fully within clang AST spirit) to not
force every single consumer to do that work, but instead store that knowledge
in the correct, and appropriate place - AST, class structure.

Now, there is another hoop we need to get through.
It isn't fully obvious //how// to model this.
The best solution would of course be to simply add a `OMPStructuredBlock` transparent
node. It would be optimal, it would give us two properties:
* Given this `OMPExecutableDirective`, what's it OpenMP structured block?
* It is trivial to  check whether the `Stmt*` is a OpenMP structured block (`isa<OMPStructuredBlock>(ptr)`)

But OpenMP structured block isn't **necessarily** the first, direct child of `OMP*Directive`.
(even ignoring the clang's `CapturedStmt`/`CapturedDecl` that were inserted inbetween).
So i'm not sure whether or not we could re-create AST statements after they were already created?
There would be other costs to a new AST node: https://bugs.llvm.org/show_bug.cgi?id=40563#c12
```
1. You will need to break the representation of loops. The body should be replaced by the "structured block" entity.
2. You will need to support serialization/deserialization.
3. You will need to support template instantiation.
4. You will need to support codegen and take this new construct to account in each OpenMP directive.
```

Instead, there **is** an functionally-equivalent, alternative solution, consisting of two parts.

Part 1:
* Add a member function `isStandaloneDirective()` to the `OMPExecutableDirective` class,
  that will tell whether this directive is stand-alone or not, as per the spec.
  We need it because we can't just check for the existance of associated statements,
  see code comment.
* Add a member function `getStructuredBlock()` to the OMPExecutableDirective` class itself,
  that assert that this is not a stand-alone directive, and either return the correct loop body
  if this is a loop-like directive, or the captured statement.
This way, given an `OMPExecutableDirective`, we can get it's structured block.
Also, since the knowledge is ingrained into the clang OpenMP implementation,
it will not cause any duplication, and //hopefully// won't bitrot.

Great we achieved 1 of 2 properties of `OMPStructuredBlock` approach.

Thus, there is a second part needed:
* How can we check whether a given `Stmt*` is `OMPStructuredBlock`?
Well, we can't really, in general. I can see this workaround:
```
class FunctionASTVisitor : public RecursiveASTVisitor<FunctionASTVisitor> {
  using Base = RecursiveASTVisitor<FunctionASTVisitor>;
public:
  bool VisitOMPExecDir(OMPExecDir *D) {
    OmpStructuredStmts.emplace_back(D.getStructuredStmt());
  }
  bool VisitSOMETHINGELSE(???) {
    if(InOmpStructuredStmt)
      HI!
  }
  bool TraverseStmt(Stmt *Node) {
    if (!Node)
      return Base::TraverseStmt(Node);
    if (OmpStructuredStmts.back() == Node)
      ++InOmpStructuredStmt;
    Base::TraverseStmt(Node);
    if (OmpStructuredStmts.back() == Node) {
      OmpStructuredStmts.pop_back();
      --InOmpStructuredStmt;
    }
    return true;
  }
  std::vector<Stmt*> OmpStructuredStmts;
  int InOmpStructuredStmt = 0;
};
```
But i really don't see using it in practice.
It's just too intrusive; and again, requires knowledge duplication.

.. but no. The solution lies right on the ground.
Why don't we simply store this `i'm a openmp structured block` in the bitfield of the `Stmt` itself?
This does not appear to have any impact on the memory footprint of the clang AST,
since it's just a single extra bit in the bitfield. At least the static assertions don't fail.
Thus, indeed, we can achieve both of the properties without a new AST node.

We can cheaply set that bit right in sema, at the end of `Sema::ActOnOpenMPExecutableDirective()`,
by just calling the `getStructuredBlock()` that we just added.
Test coverage that demonstrates all this has been added.

This isn't as great with serialization though. Most of it does not use abbrevs,
so we do end up paying the full price (4 bytes?) instead of a single bit.
That price, of course, can be reclaimed by using abbrevs.
In fact, i suspect that //might// not just reclaim these bytes, but pack these PCH significantly.

I'm not seeing a third solution. If there is one, it would be interesting to hear about it.
("just don't write code that would require `isa<OMPStructuredBlock>(ptr)`" is not a solution.)

Fixes [[ https://bugs.llvm.org/show_bug.cgi?id=40563 | PR40563 ]].

Reviewers: ABataev, rjmccall, hfinkel, rsmith, riccibruno, gribozavr

Reviewed By: ABataev, gribozavr

Subscribers: mgorny, aaron.ballman, steveire, guansong, jfb, jdoerfert, cfe-commits

Tags: #clang, #openmp

Differential Revision: https://reviews.llvm.org/D59214

llvm-svn: 356570
2019-03-20 16:32:36 +00:00
Simon Pilgrim a6e5888880 Build ASTImporterTest.cpp with /bigobj on MSVC builds to keep llvm-clang-x86_64-expensive-checks-win buildbot happy
llvm-svn: 349357
2018-12-17 15:14:08 +00:00
Fangrui Song 5313327f61 Add explicit dependency on clangSerialization for a bunch of components to fix -DBUILD_SHARED_LIBS=on build
This is a more thorough fix of rC348911.
The story about -DBUILD_SHARED_LIBS=on build after rC348907 (Move PCHContainerOperations from Frontend to Serialization) is:

1. libclangSerialization.so defines PCHContainerReader dtor, ...
2. clangFrontend and clangTooling define classes inheriting from PCHContainerReader, thus their DSOs have undefined references on PCHContainerReader dtor
3. Components depending on either clangFrontend or clangTooling cannot be linked unless they have explicit dependency on clangSerialization due to the default linker option -z defs. The explicit dependency could be avoided if libclang{Frontend,Tooling}.so had these undefined references.

This patch adds the explicit dependency on clangSerialization to make them build.

llvm-svn: 348915
2018-12-12 08:02:18 +00:00
Gabor Marton 1f667535cf [ASTImporter] Add unit tests for structural equivalence
Summary:
This patch add new tests for structural equivalence. For that a new
common header is created which holds the test related language specific
types and functions.

Reviewers: a.sidorin, xazax.hun, szepet

Subscribers: rnkovacs, dkrupp, cfe-commits

Differential Revision: https://reviews.llvm.org/D46867

llvm-svn: 333166
2018-05-24 08:41:07 +00:00
Ilya Biryukov 1ff7c32fc9 [AST] Added a helper to extract a user-friendly text of a comment.
Summary:
The helper is used in clangd for documentation shown in code completion
and storing the docs in the symbols. See D45999.

This patch reuses the code of the Doxygen comment lexer, disabling the
bits that do command and html tag parsing.
The new helper works on all comments, including non-doxygen comments.
However, it does not understand or transform any doxygen directives,
i.e. cannot extract brief text, etc.

Reviewers: sammccall, hokein, ioeric

Reviewed By: ioeric

Subscribers: mgorny, cfe-commits

Differential Revision: https://reviews.llvm.org/D46000

llvm-svn: 332458
2018-05-16 12:30:09 +00:00
Raphael Isemann be4fbcaa44 Refactor RecursiveASTVisitor test for post-order traversal
Summary:
The new test is now in the right directory with the other ASTVisitor tests and uses
now the provided TestVisitor framework.

Subscribers: hintonda, v.g.vassilev, klimek, cfe-commits, mgorny

Differential Revision: https://reviews.llvm.org/D37557

llvm-svn: 323310
2018-01-24 09:40:16 +00:00
Shoaib Meenai d806af3499 [CMake] Use PRIVATE in target_link_libraries for executables
We currently use target_link_libraries without an explicit scope
specifier (INTERFACE, PRIVATE or PUBLIC) when linking executables.
Dependencies added in this way apply to both the target and its
dependencies, i.e. they become part of the executable's link interface
and are transitive.

Transitive dependencies generally don't make sense for executables,
since you wouldn't normally be linking against an executable. This also
causes issues for generating install export files when using
LLVM_DISTRIBUTION_COMPONENTS. For example, clang has a lot of LLVM
library dependencies, which are currently added as interface
dependencies. If clang is in the distribution components but the LLVM
libraries it depends on aren't (which is a perfectly legitimate use case
if the LLVM libraries are being built static and there are therefore no
run-time dependencies on them), CMake will complain about the LLVM
libraries not being in export set when attempting to generate the
install export file for clang. This is reasonable behavior on CMake's
part, and the right thing is for LLVM's build system to explicitly use
PRIVATE dependencies for executables.

Unfortunately, CMake doesn't allow you to mix and match the keyword and
non-keyword target_link_libraries signatures for a single target; i.e.,
if a single call to target_link_libraries for a particular target uses
one of the INTERFACE, PRIVATE, or PUBLIC keywords, all other calls must
also be updated to use those keywords. This means we must do this change
in a single shot. I also fully expect to have missed some instances; I
tested by enabling all the projects in the monorepo (except dragonegg),
and configuring both with and without shared libraries, on both Darwin
and Linux, but I'm planning to rely on the buildbots for other
configurations (since it should be pretty easy to fix those).

Even after this change, we still have a lot of target_link_libraries
calls that don't specify a scope keyword, mostly for shared libraries.
I'm thinking about addressing those in a follow-up, but that's a
separate change IMO.

Differential Revision: https://reviews.llvm.org/D40823

llvm-svn: 319840
2017-12-05 21:49:56 +00:00
Johannes Altmanninger 1a2676924a [analyzer] Make StmtDataCollector customizable
Summary:
This moves the data collection macro calls for Stmt nodes
to lib/AST/StmtDataCollectors.inc

Users can subclass ConstStmtVisitor and include StmtDataCollectors.inc
to define visitor methods for each Stmt subclass. This makes it also
possible to customize the visit methods as exemplified in
lib/Analysis/CloneDetection.cpp.

Move helper methods for data collection to a new module,
AST/DataCollection.

Add data collection for DeclRefExpr, MemberExpr and some literals.

Reviewers: arphaman, teemperor!

Subscribers: mgorny, xazax.hun, cfe-commits

Differential Revision: https://reviews.llvm.org/D36664

llvm-svn: 311569
2017-08-23 16:28:26 +00:00
Vassil Vassilev 7baef47065 Recommit r274348 and r274349. The Windows failures should be fixed.
Original commit message:
"Add postorder traversal support to the RecursiveASTVisitor.

This feature needs to be explicitly enabled by overriding shouldTraversePostOrder()
as it has performance drawbacks for the iterative Stmt-traversal.

Patch by Raphael Isemann!

Reviewed by Richard Smith and Benjamin Kramer."

llvm-svn: 274830
2016-07-08 08:33:56 +00:00
Vassil Vassilev ccfadeb20f Revert r274348 and r274349 until the Windows failures are fixed.
llvm-svn: 274359
2016-07-01 16:07:57 +00:00
Vassil Vassilev 29abe10af9 Add postorder traversal support to the RecursiveASTVisitor.
This feature needs to be explicitly enabled by overriding shouldTraversePostOrder()
as it has performance drawbacks for the iterative Stmt-traversal.

Patch by Raphael Isemann!

Reviewed by Richard Smith and Benjamin Kramer.

llvm-svn: 274348
2016-07-01 13:28:31 +00:00
Artem Dergachev 4e7c6fdeeb [ASTImporter] Implement some expression-related AST node import.
Introduce ASTImporter unit test framework.

Fix a memory leak introduced in cf8ccff5: an array is allocated
in ImportArray and never freed.

Support new node kinds:

- GCCAsmStmt

- AddrLabelExpr
- AtomicExpr
- CompoundLiteralExpr
- CXXBoolLiteralExpr
- CXXNullPtrLiteralExpr
- CXXThisExpr
- DesignatedInitExpr
- GNUNullExpr
- ImplicitValueInitExpr
- InitListExpr
- OpaqueValueExpr
- PredefinedExpr
- ParenListExpr
- StmtExpr
- VAArgExpr

- BinaryConditionalOperator
- ConditionalOperator

- FloatingLiteral
- StringLiteral

- InjectedClassNameType
- TemplateTypeParmType

- LabelDecl

Patch by Aleksei Sidorin!

Differential Revision: http://reviews.llvm.org/D14286

llvm-svn: 266292
2016-04-14 11:51:27 +00:00
Richard Smith 46dd5bba44 Take PrintingPolicy::SuppressUnwrittenScope into account when printing the
qualified name of a NamedDecl. Patch by Volodymyr Sapsai!

llvm-svn: 209924
2014-05-30 22:16:51 +00:00
James Dennett 0492ef0e0b Fix a crash (assertion failure) in EvaluateAsRValue.
Summary:
Gracefully fail to evaluate a constant expression if its type is
unknown, rather than failing an assertion trying to access the type.

Reviewers: klimek

Reviewed By: klimek

CC: chandlerc, cfe-commits

Differential Revision: http://llvm-reviews.chandlerc.com/D3075

llvm-svn: 203950
2014-03-14 17:44:10 +00:00
Richard Smith 023d2ca451 Add a unittest for the ExternalASTSource.
llvm-svn: 203525
2014-03-11 01:18:47 +00:00
Richard Smith 664b32b814 Revert accidentally-committed file.
llvm-svn: 203318
2014-03-08 00:04:19 +00:00
Richard Smith 9bca298f6d Module [extern_c] attribute: inherit to submodules, don't write 'extern "C"'
blocks when building in C mode, and serialize and deserialize the attribute.

llvm-svn: 203317
2014-03-08 00:03:56 +00:00
NAKAMURA Takumi ac85179219 [CMake] Update target_link_libraries() and LLVM_LINK_COMPONENTS for each CMakeLists.txt.
llvm-svn: 196916
2013-12-10 12:40:37 +00:00
David Blaikie 67fc79f9ea Revert "Revert "PR16540: ASTVector::insert(Context, Iter, Element) doesn't compile""
This reverts commit b18b043a5a37f76803d89467e46bcac286c0ecae.

Reapply with fix for the configure+make build (missing include of
ASTContext.h).

llvm-svn: 186257
2013-07-13 19:23:35 +00:00
David Blaikie 3c0e97ca7a Revert "PR16540: ASTVector::insert(Context, Iter, Element) doesn't compile"
This reverts commit r186253.

This is failing to link under Configure+Make on the buildbots for
reasons I don't immediately understand.

llvm-svn: 186255
2013-07-13 18:54:56 +00:00
David Blaikie 4cffb8ed5c PR16540: ASTVector::insert(Context, Iter, Element) doesn't compile
Fix some uninstantiable code in ASTVector::insert. I've added a
cheap-and-dirty compile test for this, because I don't have the time to
figure out a nice way to get a real ASTContext to implement executable
tests - but we probably should have them for this ADT.

llvm-svn: 186253
2013-07-13 18:08:59 +00:00
Samuel Benzaquen f226e97dff Enhancements for the DynTypedNode
Added ASTNodeKind as a standalone way to represent node kinds and their hierarchy.
This change is to support ongoing work on D815.

Reviewers: klimek

CC: cfe-commits
llvm-svn: 184331
2013-06-19 18:45:24 +00:00
Manuel Klimek a732899cb4 Fix memory leak for APValues that do memory allocation.
This patch ensures that APValues are deallocated with the ASTContext by
registering a deallocation function for APValues to the ASTContext.

Original version of the patch by James Dennett.

llvm-svn: 183101
2013-06-03 13:51:33 +00:00
Manuel Klimek d4be4084b4 First step towards adding a parent map to the ASTContext.
This does not yet implement the LimitNode approach discussed.

The impact of this is an O(n) in the number of nodes in the AST
reduction of complexity for certain kinds of matchers (as otherwise the
parent map gets recreated for every new MatchFinder).

See FIXMEs in the comments for the direction of future work.

llvm-svn: 176251
2013-02-28 13:21:39 +00:00
Manuel Klimek e6de22d3dc Add unit tests for source locations of AST nodes.
Patch by Philip Craig.

llvm-svn: 167470
2012-11-06 17:31:40 +00:00
Dmitri Gribenko 24bef9a4e9 As a followup for r164303, add some tests for printing literals that test
printing directly rather than through a complicated machinery of ObjC rewriter.

llvm-svn: 164477
2012-09-23 20:29:07 +00:00
Dmitri Gribenko 309856ae9f DeclPrinter: add terse output mode and lots of tests
Add a flag PrintingPolicy::DontRecurseInDeclContext to provide "terse" output
from DeclPrinter.  The motivation is to use DeclPrinter to print declarations
in user-friendly format, without overwhelming user with inner detail of the
declaration being printed.

Also add many tests for DeclPrinter.  There are quite a few things that we
print incorrectly: search for WRONG in DeclPrinterTest.cpp -- and these tests
check our output against incorrect output, so that we can fix/refactor/rewrite
the DeclPrinter later.

llvm-svn: 162245
2012-08-20 23:39:06 +00:00
Dmitri Gribenko e3942ef9a4 add AST unittests to CMake build system
llvm-svn: 160640
2012-07-23 20:11:34 +00:00
Dmitri Gribenko 5188c4b9cc Implement a lexer for structured comments.
llvm-svn: 159223
2012-06-26 20:39:18 +00:00