| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
'infered' --> 'inferred'
llvm-svn: 288922
|
|
|
|
|
|
|
|
| |
No functional change intended.
Differential Revision: https://reviews.llvm.org/D27408
llvm-svn: 288917
|
|
|
|
|
|
|
|
| |
Avoids a crash and a related false positive.
Investigation by Daniel Krupp!
llvm-svn: 288914
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit fixes PR20796. It implements the C only -Wstrict-prototypes warning.
Clang now emits a warning for function declarations which have no parameters
specified and for K&R function definitions with more than 0 parameters that are
not preceded by a previous prototype declaration.
The patch was originally submitted by Paul Titei!
rdar://15060615
Differential Revision: https://reviews.llvm.org/D16533
llvm-svn: 288896
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
an Objective-C declaration
This commit ensures that Sema won't enter a C++ declarator scope when the
current context is an Objective-C declaration. This prevents an assertion
failure in EnterDeclaratorContext that's used to ensure that current context
will be restored correctly after exiting the declarator context.
rdar://20560175
Differential Revision: https://reviews.llvm.org/D26922
llvm-svn: 288893
|
|
|
|
|
|
|
|
|
|
|
|
| |
Patch by Egor Churaev (echuraev).
Reviewers: Anastasia
Subscribers: bader, yaxunl, cfe-commits
Differential Revision: https://reviews.llvm.org/D27300
llvm-svn: 288890
|
|
|
|
|
|
|
|
|
|
|
|
| |
As a first step toward removing Objective-C garbage collection from
Clang, remove support from the driver. I'm hoping this will flush out
any expected bots/configurations/whatever that might rely on it.
I've left the options behind temporarily in -cc1 to keep tests passing.
I'll kill them off entirely in a follow up when I've had a chance to
update/delete the rest of Clang.
llvm-svn: 288872
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ctor in window. Need add "complete object flag" check in eh cleanup code.
The problem only happen on window ( A MS-ABI issuer )
The nature of the problem is virtual base dtor called more than it is needed after exception throw in inheriting base class(with virtual bases) ctor.
The root problem is when throw happen, not all virtual base classes have been contructed, so not all virtual base dtors are need to call for ehcleanup.
clang has code to handle vbase initialization: basically add check for "complete object flag" before call to v-base ctor.
But that part is missing for cleanup code.
To fix this add similar code as v-base init to cleanup code, same algorithm.
1> Add new routine:
EmitDtorCompleteObjectHandler
With corresponding to EmitCtorCompleteObjectHandler
2> In the EmitDestructorCal
Call EmitDtorCompleteObjectHandler when generate ehcleanup inside ctor.
Just add check for "complete object flag" before call to v-base dtor.
Without my change:
ehcleanup: ; preds = %ctor.skip_vbases
%13 = cleanuppad within none [], !dbg !66
%14 = bitcast %struct.class_0* %this1 to i8*, !dbg !66
%15 = getelementptr inbounds i8, i8* %14, i64 8, !dbg !66
%16 = bitcast i8* %15 to %struct.class_2*, !dbg !66
call void @"\01??1class_2@@UEAA@XZ"(%struct.class_2* %16) #6 [ "funclet"(token
%13) ], !dbg !66
cleanupret from %13 unwind to caller, !dbg !66
with my change:
ehcleanup: ; preds = %ctor.skip_vbases
%13 = cleanuppad within none [], !dbg !66
%14 = bitcast %struct.class_0* %this1 to i8*, !dbg !66
%15 = getelementptr inbounds i8, i8* %14, i64 8, !dbg !66
%16 = bitcast i8* %15 to %struct.class_2*, !dbg !66
%is_complete_object4 = icmp ne i32 %is_most_derived2, 0, !dbg !66
br i1 %is_complete_object4, label %Dtor.dtor_vbase, label %Dtor.skip_vbase, !d
bg !66
Dtor.dtor_vbase: ; preds = %ehcleanup
call void @"\01??1class_2@@UEAA@XZ"(%struct.class_2* %16) #6 [ "funclet"(token
%13) ], !dbg !66
br label %Dtor.skip_vbase, !dbg !66
Dtor.skip_vbase: ; preds = %Dtor.dtor_vbase, %ehcleanup
cleanupret from %13 unwind to caller, !dbg !66
Please let me know you need more info.
Patch by Jennifer Yu.
Differential Revision: https://reviews.llvm.org/D27358
llvm-svn: 288869
|
|
|
|
| |
llvm-svn: 288868
|
|
|
|
|
|
|
|
| |
When an object of class type is initialized from a prvalue of the same type
(ignoring cv qualifications), use the prvalue to initialize the object directly
instead of inserting a redundant elidable call to a copy constructor.
llvm-svn: 288866
|
|
|
|
|
|
|
|
|
|
|
|
| |
Our -Wweak-vtables diagnostic is powered by our key function
calculation, which checks if key functions are enabled. We won't find
any key functions in C++ ABIs that lack key functions, so -Wweak-vtables
was warning on every dynamic class before this change. So, turn off this
warning in ABIs without key functions.
Addresses PR31220
llvm-svn: 288850
|
|
|
|
|
|
|
|
|
|
|
|
| |
We didn't implement handle corner cases like:
- lambdas used to initialize a field
- lambdas in default argument initializers
This fixes PR31197.
Differential Revision: https://reviews.llvm.org/D27226
llvm-svn: 288826
|
|
|
|
|
|
| |
is seen, record one with the implicit default.
llvm-svn: 288822
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When integrating compilation database output into existing build
systems, two approaches dominate so far. Ad-hoc implementation of the
JSON output rules or using compiler wrappers. This patch adds a new
option "-MJ foo.json" which gives a slightly cleaned up compilation
record. The output is a fragment, i.e. you still need to add the array
markers, but it allows multiple files to be easy merged.
This way the only change in a build system is adding the option with
potentially a per-target output file and merging the files with
something like
(echo '['; cat *.o.json; echo ']' > compilation_database.json
or some additional filtering to remove the trailing comma for strict
JSON compliance.
Differential Revision: https://reviews.llvm.org/D27140
llvm-svn: 288821
|
|
|
|
|
|
| |
Patch by Michael Sharpe.
llvm-svn: 288813
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Related llvm patch: https://reviews.llvm.org/D27359
Reviewers: echristo, t.p.northover, rengolin, grosbach, compnerd
Subscribers: mehdi_amini, cfe-commits, llvm-commits
Tags: #clang-c
Differential Revision: https://reviews.llvm.org/D27360
llvm-svn: 288762
|
|
|
|
|
|
|
|
|
| |
- Rename CheckMinZero to CheckMaxUnsignedZero to reflect its actual purpose.
- Remove unused parameters from CheckAbsoluteValueFunction and
CheckMaxUnsignedZero functions.
- Refactor the function name check so both functions can use the same one.
llvm-svn: 288756
|
|
|
|
|
|
| |
Recover better from an incompatible .pcm file being provided by -fmodule-file=. We try to include the headers of the module textually in this case, still enforcing the modules semantic rules. In order to make that work, we need to still track that we're entering and leaving the module. Also, if the module was also marked as unavailable (perhaps because it was missing a file), we shouldn't mark the module unavailable -- we don't need the module to be complete if we're going to enter it textually.
llvm-svn: 288741
|
|
|
|
|
|
|
|
| |
import can't appear here" diagnostic if an already-visible module is textually
entered (because we have the module map but not the AST file) within a
function/namespace scope.
llvm-svn: 288737
|
|
|
|
|
|
|
|
|
|
|
| |
New default warning that triggers when an unsigned zero is used in a call to
std::max. For unsigned values, zero is the minimum value, so any call to
std::max is always equal to the other value. A common pattern was to take
the max of zero and the difference of two unsigned values, not taking into
account that unsigned values wrap around below zero. This warning also emits
a note with a fixit hint to remove the zero and call to std::max.
llvm-svn: 288732
|
|
|
|
|
|
|
|
|
| |
When emitting RTTI for EH only, we would mark the locally defined (LinkOnceODR)
RTTI definition as dllimport, which is incorrect. Ensure that if we are
generating the type information for EH only, it is marked as LinkOnceODR and we
do not make it dllimport.
llvm-svn: 288721
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: NoQ, dcoughlin, zaks.anna
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D27365
llvm-svn: 288696
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Similar to r288685.
getExceptionSpec returned structure with pointers to temporarily object created
by computeImplicitExceptionSpec.
Reviewers: rsmith
Subscribers: aizatsky, cfe-commits
Differential Revision: https://reviews.llvm.org/D27422
llvm-svn: 288689
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
getExceptionSpec returns structure with pointers to temporarily object created
by computeImplicitExceptionSpec.
Reviewers: rsmith
Subscribers: aizatsky, cfe-commits
Differential Revision: https://reviews.llvm.org/D27420
llvm-svn: 288685
|
|
|
|
|
|
|
|
|
|
|
| |
On MSVC, if an implicit instantiation already exists and an explicit
instantiation definition with a DLL attribute is created, the DLL
attribute still takes effect. Make clang match this behavior for
exporting.
Differential Revision: https://reviews.llvm.org/D26657
llvm-svn: 288682
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On a method call, the ObjCGenerics checker uses the type tracked by
DynamicTypePropagation for the receiver to to infer substituted parmeter types
for the called methods and warns when the argument type does not match the
parameter.
Unfortunately, using the tracked type can result in false positives when the
receiver has a non-invariant type parameter and has been intentionally upcast.
For example, becaue NSArray's type parameter is covaraint, the following code
is perfectly safe:
NSArray<NSString *> *allStrings = ...
NSDate *date = ...;
NSArray<NSObject *> *allObjects = allStrings;
NSArray<NSObject *> *moreObjects = [allObjects arrayByAddingObject:date];
but the checker currently warns that the date parameter is not an NSString *.
To avoid this kind of false positive, the checker will now only warn when
the class defining the called method has only invariant type parameters.
rdar://problem/28803951
llvm-svn: 288677
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
CXXDeleteExpr::getDestroyedType() can return a null QualType if the destroyed
type is a dependent type. This patch protects against this.
Reviewers: klimek
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D27350
llvm-svn: 288665
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
latter case, a temporary array object is materialized, and can be
lifetime-extended by binding a reference to the member access. Likewise, in an
array-to-pointer decay, an rvalue array is materialized before being converted
into a pointer.
This caused IR generation to stop treating file-scope array compound literals
as having static storage duration in some cases in C++; that has been rectified
by modeling such a compound literal as an lvalue. This also improves clang's
compatibility with GCC for those cases.
llvm-svn: 288654
|
|
|
|
| |
llvm-svn: 288629
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-fmodule-file=. We try to include the headers of the module textually in this case, still enforcing the modules semantic rules. In order to make that work, we need to still track that we're entering and leaving the module. Also, if the module was also marked as unavailable (perhaps because it was missing a file), we shouldn't mark the module unavailable -- we don't need the module to be complete if we're going to enter it textually."
This reverts commit r288449.
I believe that this is currently faulty wrt. modules being imported
inside namespaces. Adding these lines to the new test:
namespace n {
#include "foo.h"
}
Makes it break with
fatal error: import of module 'M' appears within namespace 'n'
However, I believe it should fail with
error: redundant #include of module 'M' appears within namespace 'n'
I have tracked this down to us now inserting a tok::annot_module_begin
instead of a tok::annot_module_include in
Preprocessor::HandleIncludeDirective() and then later in
Parser::parseMisplacedModuleImport(), we hit the code path for
tok::annot_module_begin, which doesn't set FromInclude of
checkModuleImportContext to true (thus leading to the "wrong"
diagnostic).
llvm-svn: 288626
|
|
|
|
|
|
|
| |
Revert r288447 which introduced -mdirect. It turns out we don't need a
custom flag for this, as the information we need is in the target triple.
llvm-svn: 288604
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
An explicit template specialization can cause the implicit template
specialization of a type which inherits the attributes. In such a case, we
would end up with a delayed template specialization for a dll exported type
which we would fail to reference. This would trigger an assertion.
We now propagate the dll storage attributes through the inheritance
chain. Only after having done so do we reference the delayed template
specializations. This allows any implicit specializations which inherit dll
storage to also be referenced.
llvm-svn: 288570
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
constructors
Summary:
The C++17 rules for aggregate initialization changed to disallow types with explicit constructors [dcl.init.aggr]p1. This patch implements that new rule.
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D25654
llvm-svn: 288565
|
|
|
|
|
|
|
| |
temporary produces an xvalue, not a prvalue. Support this by materializing the
temporary prior to performing the member access.
llvm-svn: 288563
|
|
|
|
|
|
|
| |
compute whether a call is noexcept, even if we can't map the callee expression
to a called declaration.
llvm-svn: 288558
|
|
|
|
|
|
| |
In passing, add a warning group for "ignored qualifier in inline assembly" warnings.
llvm-svn: 288548
|
|
|
|
|
|
|
|
| |
When a C++ record is marked with dllexport mark both the typeinfo and the
typeinfo name as being exported. Handle dllimport as the inverse. This applies
to the itanium environment and not the MinGW environment.
llvm-svn: 288546
|
|
|
|
| |
llvm-svn: 288545
|
|
|
|
|
|
| |
Looks like the reset() call was omitted by accident.
llvm-svn: 288534
|
|
|
|
|
|
|
|
|
|
| |
This is to match the behavior of non-LTO;
when -fsave-optimization-record is passed and PGO is available we enable
the generation of hotness information in the optimization records.
Differential Revision: https://reviews.llvm.org/D27332
llvm-svn: 288520
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is an improvement on rL288448 where address sanitization was listed
as supported for the CudaToolChain. Since the intent is for the
CudaToolChain not to reject any flags supported by the host compiler,
this patch switches to forwarding the CudaToolChain sanitizer support to
the host toolchain rather than explicitly whitelisting address
sanitization.
Thanks to hfinkel for this suggestion.
Reviewers: jlebar
Subscribers: hfinkel, cfe-commits
Differential Revision: https://reviews.llvm.org/D27351
llvm-svn: 288512
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
of the file.
Summary:
This avoid inserting #include into:
- raw string literals containing #include.
- #if block.
- Special #include among declarations (e.g. functions).
Reviewers: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D26909
llvm-svn: 288493
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
removed as a duplicate header search path
The commit r126167 started passing the First index into RemoveDuplicates, but
forgot to update 0 to First in the loop that looks for the duplicate. This
resulted in a bug where an -iquoted search path was incorrectly removed if you
passed in the same path into -iquote and more than one time into -isystem.
rdar://23991350
Differential Revision: https://reviews.llvm.org/D27298
llvm-svn: 288491
|
|
|
|
| |
llvm-svn: 288452
|
|
|
|
|
|
|
|
|
|
|
| |
We try to include the headers of the module textually in this case, still
enforcing the modules semantic rules. In order to make that work, we need to
still track that we're entering and leaving the module. Also, if the module was
also marked as unavailable (perhaps because it was missing a file), we
shouldn't mark the module unavailable -- we don't need the module to be
complete if we're going to enter it textually.
llvm-svn: 288449
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes a bug that was introduced in rL287285. The bug made it
illegal to pass -fsanitize=address during CUDA compilation because the
CudaToolChain class was switched from deriving from the Linux toolchain
class to deriving directly from the ToolChain toolchain class. When
CudaToolChain derived from Linux, it used Linux's getSupportedSanitizers
method, and that method allowed ASAN, but when it switched to deriving
directly from ToolChain, it inherited a getSupportedSanitizers method
that didn't allow for ASAN.
This patch fixes that bug by creating a getSupportedSanitizers method
for CudaToolChain that supports ASAN.
This patch also fixes the test that checks that -fsanitize=address is
passed correctly for CUDA builds. That test didn't used to notice if an
error message was emitted, and that's why it didn't catch this bug when
it was first introduced. With the fix from this patch, that test will
now catch any similar bug in the future.
llvm-svn: 288448
|
|
|
|
|
|
|
| |
Add a target flag for enabling the new direct wasm object emission
feature.
llvm-svn: 288447
|
|
|
|
|
|
|
|
| |
After r256463, both the LHS and RHS now refer to the same variable. Before,
they referred to the member, the parameter respectively. Now GCC6's
-Wtautological-compare complains.
llvm-svn: 288444
|
|
|
|
|
|
|
| |
to do this unconditionally, given that the indices will always be small
constant integers anyway.
llvm-svn: 288440
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In bigger projects like an Operating System, the same source code is
often compiled in slightly different ways. This could be the difference
between PIC and non-PIC code for static vs dynamic libraries, it could
also be the difference between size optimised versions of tools for
ramdisk images. At the moment, the compilation database has no way to
distinguish such cases. As first step, add a field in the JSON format
for it and process it accordingly.
Differential Revision: https://reviews.llvm.org/D27138
llvm-svn: 288436
|