This is a stopgap fix for PR31863, a regression introduced in r276159.
Consider this snippet:
struct FVector;
struct FVector {};
struct FBox {
FVector Min;
FBox(int);
};
namespace {
FBox InvalidBoundingBox(0);
}
While parsing the DECL_VAR for 'struct FBox', clang recursively read all the
dep decls until it finds the DECL_CXX_RECORD forward declaration for 'struct
FVector'. Then, it resumes all the way up back to DECL_VAR handling in
`ReadDeclRecord`, where it checks if `isConsumerInterestedIn` for the decl.
One of the condition for `isConsumerInterestedIn` to return false is if the
VarDecl is imported from a module `D->getImportedOwningModule()`, because it
will get emitted when we import the relevant module. However, before checking
if it comes from a module, clang checks if `Ctx.DeclMustBeEmitted(D)`, which
triggers the emission of 'struct FBox'. Since one of its fields is still
incomplete, it crashes.
Instead, check if `D->getImportedOwningModule()` is true before calling
`Ctx.DeclMustBeEmitted(D)`.
Differential Revision: https://reviews.llvm.org/D29753
rdar://problem/30173654
llvm-svn: 296656
and the nature of a declaration
This commit adds an external_source_symbol attribute to Clang. This attribute
specifies that a declaration originates from an external source and describes
the nature of that source. This attribute will be used to improve IDE features
like 'jump-to-definition' for mixed-language projects or project that use
auto-generated code.
rdar://30423368
Differential Revision: https://reviews.llvm.org/D29819
llvm-svn: 296649
In the following code involving GNU statement-expression extension:
struct S {
~S();
};
void foo() {
const S &x = ({ return; S(); });
}
function 'foo()' returns before reference x is initialized. We shouldn't call
the destructor for the temporary object lifetime-extended by 'x' in this case,
because the object never gets constructed in the first place.
The real problem is probably in the CFG somewhere, so this is a quick-and-dirty
hotfix rather than the perfect solution.
A patch by Artem Dergachev!
rdar://problem/30759076
Differential Revision: https://reviews.llvm.org/D30499
llvm-svn: 296646
Summary:
Don't warn about unused lambda captures that involve copying a
value of a type that cannot be trivially copied and destroyed.
Fixes PR31977
Reviewers: rsmith, aaron.ballman
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D30327
llvm-svn: 296602
potential capture list.
Fix Sema::getCurLambda() to return the innermost lambda scope when there
is a block enclosed in the lambda. Previously, the method would return a
nullptr in such cases, which would prevent a variable captured by the
enclosed block to be added to the lambda scope's potential capture list.
rdar://problem/28412462
Differential Revision: https://reviews.llvm.org/D25556
llvm-svn: 296584
The exisiting warning for inconsistent overrides does not include the destructor
as it was noted in review that it was too noisy. Instead, add to a separate
warning group that is off by default for users who want consistent warnings
between methods and destructors.
llvm-svn: 296572
Fix a crash in the ObjCPropertyChecker when analyzing a 'copy' property of an
NSMutable* type in a protocol.
rdar://problem/30766684
Differential Revision: https://reviews.llvm.org/D30482
llvm-svn: 296562
The option -mexecute-only is translated into the backend option
-arm-execute-only. But this option only makes sense for the compiler and
the assembler does not recognize it. This patch stops clang from passing
this option to the assembler.
Change-Id: I4f4cb1162c13cfd50a0a36702a4ecab1bc0324ba
Review: https://reviews.llvm.org/D30414
llvm-svn: 296454
The begining command "rm" will return 1 when there is not such file to
delete.
This patch is to remove it, as it's not needed for the test.
llvm-svn: 296453
Second attempt after http://llvm.org/viewvc/llvm-project?rev=296166&view=rev
In the first attempt, Code (the memory buffer backing the input file) was reset
before overwriteChangedFiles() was called, but overwriteChangedFiles() still
reads from it. This time, load the whole input file into memory instead of
using mmap when formatting in-place.
(Since the test is identical to what was in the repo before chapuni's revert,
svn diff doesn't show it – see the above link for the test.)
https://reviews.llvm.org/D30385
llvm-svn: 296408
When clang emits an inheriting C++ constructor it may inline code
during the CodeGen phase. This patch ensures that any debug info in
this inlined code gets a proper inlined location. Otherwise we can end
up with invalid debug info metadata, since all inlined local variables
and function arguments would be reparented into the call site.
Analogous to ApplyInlineLocation this patch introduces a
ApplyInlineDebugLocation scoped helper to facilitate entering an
inlined scope and cleaning up afterwards.
This fixes one of the issues discovered in PR32042.
rdar://problem/30679307
llvm-svn: 296388
Summary: This enables LTO to be used with the clang-cl frontend.
Reviewers: rnk, hans
Reviewed By: hans
Subscribers: pcc, cfe-commits, mehdi_amini, Prazek
Differential Revision: https://reviews.llvm.org/D30239
llvm-svn: 296373
Parameters have a 'child' relation to their function/method.
Also add an option '-include-locals' to 'c-index-test core' to enable indexing of function-local symbols.
Original patch from Nathan Hawes with some changes by me.
https://reviews.llvm.org/D30304
llvm-svn: 296282
Essentially, as a base class constructor does not construct virtual bases, such
a constructor for an abstract class does not need the corresponding base class
construction to be valid, and likewise for destructors.
This creates an awkward situation: clang will sometimes generate references to
the complete object and deleting destructors for an abstract class (it puts
them in the construction vtable for a derived class). But we can't generate a
"correct" version of these because we can't generate references to base class
constructors any more (if they're template specializations, say, we might not
have instantiated them and can't assume any other TU will emit a copy).
Fortunately, we don't need to, since no correct program can ever invoke them,
so instead emit symbols that just trap.
We should stop emitting references to these symbols, but still need to emit
definitions for compatibility.
llvm-svn: 296275
This get the resource dir string to match with the one from libclang (which is not adding '/../'),
and allows clang to accept a modules-enabled PCH that was created by libclang.
llvm-svn: 296262
2nd attempt: the first was in r296231, but it had a use after lifetime
bug.
Clang has logic to lower certain conditional expressions directly into llvm
select instructions. However, it does not emit the correct profile counter
increment as it does this: it emits an unconditional increment of the counter
for the 'then branch', even if the value selected is from the 'else branch'
(this is PR32019).
That means, given the following snippet, we would report that "0" is selected
twice, and that "1" is never selected:
int f1(int x) {
return x ? 0 : 1;
^2 ^0
}
f1(0);
f1(1);
Fix the problem by using the instrprof_increment_step intrinsic to do the
proper increment.
llvm-svn: 296245
Clang has logic to lower certain conditional expressions directly into
llvm select instructions. However, it does not emit the correct profile
counter increment as it does this: it emits an unconditional increment
of the counter for the 'then branch', even if the value selected is from
the 'else branch' (this is PR32019).
That means, given the following snippet, we would report that "0" is
selected twice, and that "1" is never selected:
int f1(int x) {
return x ? 0 : 1;
^2 ^0
}
f1(0);
f1(1);
Fix the problem by using the instrprof_increment_step intrinsic to do
the proper increment.
llvm-svn: 296231
Teach ubsan to diagnose remainder operations which have undefined
behavior due to signed overflow (e.g INT_MIN % -1).
Differential Revision: https://reviews.llvm.org/D29437
llvm-svn: 296214
C requires the operands of arithmetic expressions to be promoted if
their types are smaller than an int. Ubsan emits overflow checks when
this sort of type promotion occurs, even if there is no way to actually
get an overflow with the promoted type.
This patch teaches clang how to omit the superflous overflow checks
(addressing PR20193).
Testing: check-clang and check-ubsan.
Differential Revision: https://reviews.llvm.org/D29369
llvm-svn: 296213
Dominic Chen