Use CTAD on llvm::SaveAndRestore

Reviewed By: dblaikie

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

[Clang][C++20] Support capturing structured bindings in lambdas

This completes the implementation of P1091R3 and P1381R1.

This patch allow the capture of structured bindings
both for C++20+ and C++

[Clang][C++20] Support capturing structured bindings in lambdas

This completes the implementation of P1091R3 and P1381R1.

This patch allow the capture of structured bindings
both for C++20+ and C++17, with extension/compat warning.

In addition, capturing an anonymous union member,
a bitfield, or a structured binding thereof now has a
better diagnostic.

We only support structured bindings - as opposed to other kinds
of structured statements/blocks. We still emit an error for those.

In addition, support for structured bindings capture is entirely disabled in
OpenMP mode as this needs more investigation - a specific diagnostic indicate the feature is not yet supported there.

Note that the rest of P1091R3 (static/thread_local structured bindings) was already implemented.

at the request of @shafik, i can confirm the correct behavior of lldb wit this change.

Fixes https://github.com/llvm/llvm-project/issues/54300
Fixes https://github.com/llvm/llvm-project/issues/54300
Fixes https://github.com/llvm/llvm-project/issues/52720

Reviewed By: aaron.ballman

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

show more ...

Revert "[Clang][C++20] Support capturing structured bindings in lambdas"

This reverts commit 44f2baa3804a62ca793f0ff3e43aa71cea91a795.

Breaks self builds and seems to have conformance issues.

[Clang][C++20] Support capturing structured bindings in lambdas

This completes the implementation of P1091R3 and P1381R1.

This patch allow the capture of structured bindings
both for C++20+ and C++

[Clang][C++20] Support capturing structured bindings in lambdas

This completes the implementation of P1091R3 and P1381R1.

This patch allow the capture of structured bindings
both for C++20+ and C++17, with extension/compat warning.

In addition, capturing an anonymous union member,
a bitfield, or a structured binding thereof now has a
better diagnostic.

We only support structured bindings - as opposed to other kinds
of structured statements/blocks. We still emit an error for those.

In addition, support for structured bindings capture is entirely disabled in
OpenMP mode as this needs more investigation - a specific diagnostic indicate the feature is not yet supported there.

Note that the rest of P1091R3 (static/thread_local structured bindings) was already implemented.

at the request of @shafik, i can confirm the correct behavior of lldb wit this change.

Fixes https://github.com/llvm/llvm-project/issues/54300
Fixes https://github.com/llvm/llvm-project/issues/54300
Fixes https://github.com/llvm/llvm-project/issues/52720

Reviewed By: aaron.ballman

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

show more ...

[clang] Add a raw_ostream operator<< overload for QualType

Under the hood this prints the same as `QualType::getAsString()` but cuts out the middle-man when that string is sent to another raw_ostrea

[clang] Add a raw_ostream operator<< overload for QualType

Under the hood this prints the same as `QualType::getAsString()` but cuts out the middle-man when that string is sent to another raw_ostream.

Also cleaned up all the call sites where this occurs.

Reviewed By: aaron.ballman

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

show more ...

[NFC][analyzer] Return underlying strings directly instead of OS.str()

This avoids an unnecessary copy required by 'return OS.str()', allowing
instead for NRVO or implicit move. The .str() call (whi

[NFC][analyzer] Return underlying strings directly instead of OS.str()

This avoids an unnecessary copy required by 'return OS.str()', allowing
instead for NRVO or implicit move. The .str() call (which flushes the
stream) is no longer required since 65b13610a5226b84889b923bae884ba395ad084d,
which made raw_string_ostream unbuffered by default.

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

show more ...

[analyzer][NFC] Display the correct function name even in crash dumps

The `-analyzer-display-progress` displayed the function name of the
currently analyzed function. It differs in C and C++. In C++

[analyzer][NFC] Display the correct function name even in crash dumps

The `-analyzer-display-progress` displayed the function name of the
currently analyzed function. It differs in C and C++. In C++, it
prints the argument types as well in a comma-separated list.
While in C, only the function name is displayed, without the brackets.
E.g.:

C++: foo(), foo(int, float)
C: foo

In crash traces, the analyzer dumps the location contexts, but the
string is not enough for `-analyze-function` in C++ mode.
This patch addresses the issue by dumping the proper function names
even in stack traces.

Reviewed By: NoQ

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

show more ...

AnalysisDeclContext::ManagedAnalyses: Use unique_ptr to simplify memory management

[analyzer] AnalysisDeclContext: Refactor and documentation

Summary:
`ScopeContext` wanted to be a thing, but sadly it is dead code.

If you wish to continue the work in D19979, here was a tiny code

[analyzer] AnalysisDeclContext: Refactor and documentation

Summary:
`ScopeContext` wanted to be a thing, but sadly it is dead code.

If you wish to continue the work in D19979, here was a tiny code which
could be reused, but that tiny and that dead, I felt that it is unneded.

Note: Other changes are truly uninteresting.

Reviewed By: NoQ

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

show more ...

[Clang] Migrate llvm::make_unique to std::make_unique

Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
o

[Clang] Migrate llvm::make_unique to std::make_unique

Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of (hopefully) all the llvm::make_unique instances across the monorepo.

Differential revision: https://reviews.llvm.org/D66259

llvm-svn: 368942

show more ...

[analyzer] StackFrameContext: Add NodeBuilderContext::blockCount() to its profile

Summary:
It allows discriminating between stack frames of the same call that is
called multiple times in a loop.

Th

[analyzer] StackFrameContext: Add NodeBuilderContext::blockCount() to its profile

Summary:
It allows discriminating between stack frames of the same call that is
called multiple times in a loop.

Thanks to Artem Dergachev for the great idea!

Reviewed By: NoQ

Tags: #clang

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

llvm-svn: 367608

show more ...

[analyzer] exploded-graph-rewriter: Improve source location dumps.

- Correctly display macro expansion and spelling locations.
- Use the same procedure to display location context call site location

[analyzer] exploded-graph-rewriter: Improve source location dumps.

- Correctly display macro expansion and spelling locations.
- Use the same procedure to display location context call site locations.
- Display statement IDs for program points.

llvm-svn: 365861

show more ...

[analyzer] Fix JSON dumps for location contexts.

Location context ID is a property of the location context, not of an item
within it. It's useful to know the id even when there are no items
in the c

[analyzer] Fix JSON dumps for location contexts.

Location context ID is a property of the location context, not of an item
within it. It's useful to know the id even when there are no items
in the context, eg. for the purposes of figuring out how did contents
of the Environment for the same location context changed across states.

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

llvm-svn: 363895

show more ...

[analyzer] print() JSONify: Environment implementation

Summary: -

Reviewers: NoQ, xazax.hun, ravikandhadai, baloghadamsoftware, Szelethus

Reviewed By: NoQ

Subscribers: szepet, rnkovacs, a.sidorin

[analyzer] print() JSONify: Environment implementation

Summary: -

Reviewers: NoQ, xazax.hun, ravikandhadai, baloghadamsoftware, Szelethus

Reviewed By: NoQ

Subscribers: szepet, rnkovacs, a.sidorin, mikhail.ramalho, donat.nagy,
dkrupp

Tags: #clang

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

llvm-svn: 361976

show more ...

[CFG] Add branch to skip vbase inits when they're handled by superclass.

This patch adds the run-time CFG branch that would skip initialization of
virtual base classes depending on whether the const

[CFG] Add branch to skip vbase inits when they're handled by superclass.

This patch adds the run-time CFG branch that would skip initialization of
virtual base classes depending on whether the constructor is called from a
superclass constructor or not. Previously the Static Analyzer was already
skipping virtual base-class initializers in such constructors, but it wasn't
skipping their arguments and their potential side effects, which was causing
pr41300 (and was generally incorrect). The previous skipping behavior is
now replaced with a hard assertion that we're not even getting there due
to how our CFG works.

The new CFG element is under a CFG build option so that not to break other
consumers of the CFG by this change. Static Analyzer support for this change
is implemented.

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

llvm-svn: 361681

show more ...

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636

show more ...

[analyzer] Generate and use stable identifiers for LocationContext

Those are not created in the allocator.
Since they are created fairly rarely, a counter overhead should not
affect the memory consu

[analyzer] Generate and use stable identifiers for LocationContext

Those are not created in the allocator.
Since they are created fairly rarely, a counter overhead should not
affect the memory consumption.

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

llvm-svn: 342314

show more ...

Remove PseudoConstantAnalysis

Summary: It's not used anywhere for years. The last usage is removed in https://reviews.llvm.org/rL198476 in 2014.

Subscribers: mgorny, cfe-commits

Differential Revis

Remove PseudoConstantAnalysis

Summary: It's not used anywhere for years. The last usage is removed in https://reviews.llvm.org/rL198476 in 2014.

Subscribers: mgorny, cfe-commits

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

llvm-svn: 342246

show more ...

Port getLocStart -> getBeginLoc

Reviewers: teemperor!

Subscribers: jholewinski, whisperity, jfb, cfe-commits

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

llvm-svn: 339385

Remove trailing space

sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h}

llvm-svn: 338291

[CFG] [analyzer] Add construction contexts that explain pre-C++17 copy elision.

Before C++17 copy elision was optional, even if the elidable copy/move
constructor had arbitrary side effects. The eli

[CFG] [analyzer] Add construction contexts that explain pre-C++17 copy elision.

Before C++17 copy elision was optional, even if the elidable copy/move
constructor had arbitrary side effects. The elidable constructor is present
in the AST, but marked as elidable.

In these cases CFG now contains additional information that allows its clients
to figure out if a temporary object is only being constructed so that to pass
it to an elidable constructor. If so, it includes a reference to the elidable
constructor's construction context, so that the client could elide the
elidable constructor and construct the object directly at its final destination.

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

llvm-svn: 335795

show more ...

[analyzer] [NFC] A convenient getter for getting a current stack frame

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

llvm-svn: 335701

[Analysis] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC).

llvm-svn: 328063

[analyzer] Add scope information to CFG

This patch adds two new CFG elements CFGScopeBegin and CFGScopeEnd that indicate
when a local scope begins and ends respectively. We use first VarDecl declare

[analyzer] Add scope information to CFG

This patch adds two new CFG elements CFGScopeBegin and CFGScopeEnd that indicate
when a local scope begins and ends respectively. We use first VarDecl declared
in a scope to uniquely identify it and add CFGScopeBegin and CFGScopeEnd elements
into corresponding basic blocks.

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

llvm-svn: 327258

show more ...

[CFG] Add extra context to C++ constructor statement elements.

This patch adds a new CFGStmt sub-class, CFGConstructor, which replaces
the regular CFGStmt with CXXConstructExpr in it whenever the CF

[CFG] Add extra context to C++ constructor statement elements.

This patch adds a new CFGStmt sub-class, CFGConstructor, which replaces
the regular CFGStmt with CXXConstructExpr in it whenever the CFG has additional
information to provide regarding what sort of object is being constructed.

It is useful for figuring out what memory is initialized in client of the
CFG such as the Static Analyzer, which do not operate by recursive AST
traversal, but instead rely on the CFG to provide all the information when they
need it. Otherwise, the statement that triggers the construction and defines
what memory is being initialized would normally occur after the
construct-expression, and the client would need to peek to the next CFG element
or use statement parent map to understand the necessary facts about
the construct-expression.

As a proof of concept, CFGConstructors are added for new-expressions
and the respective test cases are provided to demonstrate how it works.

For now, the only additional data contained in the CFGConstructor element is
the "trigger statement", such as new-expression, which is the parent of the
constructor. It will be significantly expanded in later commits. The additional
data is organized as an auxiliary structure - the "construction context",
which is allocated separately from the CFGElement.

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

llvm-svn: 324668

show more ...