by lambdas with an explicit capture list
This commit avoids the -Wshadow warning for variables which shadow variables
that aren't captured by lambdas with an explicit capture list. It provides an
additional note that points to location of the explicit capture.
The old behaviour is preserved with -Wshadow-all or -Wshadow-uncaptured-local.
rdar://17135966
Differential Revision: https://reviews.llvm.org/D26278
llvm-svn: 286354
The ObjC class protocol list assumes there is an associated location for each protocol but no location is provided
when the protocol list comes from a typedef, and we end up with a buffer overflow when trying to get locations for the protocol names.
Fixes crash of rdar://28980278.
llvm-svn: 286331
Summary:
Previously we'd look at the GVALinkage of whatever FunctionDecl you
happened to be calling.
This is not right. In the absence of the gnu_inline attribute, to be
handled separately, the function definition determines the function's
linkage. So we need to wait until we get a def before we can know
whether something is known-emitted.
Reviewers: tra
Subscribers: cfe-commits, rsmith
Differential Revision: https://reviews.llvm.org/D26268
llvm-svn: 286313
The exact same test guards entry into the loop in which this test
occurs, and there is nothing inside the loop that assigns to the
variable, so it has already been checked for null.
This was flagged by PVS-Studio as well, but the report is actually wrong
-- this is not a case where we dereference a variable prior to testing
it for null, this is a case where we have a redundant test for null
after we already performed the exact same test.
llvm-svn: 285983
corresponds to another argument being valid.
This makes it clear that the code is correct despite the PVS-Studio
report that a pointer might be dereferenced prior to being checked for
whether it is null. It likely is also enough for static analyzers to not
flag the code.
llvm-svn: 285982
dereferenced the pointer at this point, and these routines are
exclusively called after the parser encounters a code completion token.
Other code completion routines called at that point do not check for
null either, so this is clearly the current invariant expected in the
code.
This fixes another PVS-Studio found issue.
llvm-svn: 285980
and FatalErrorOccurred are both set.
This fixes a crash that occurs when a warning promoted to a fatal error
leaves the AST in an incomplete state, and then later CFG analysis is
run on the incomplete AST.
rdar://problem/28558923
Differential Revision: https://reviews.llvm.org/D26166
llvm-svn: 285923
The assignment to NextIsDereference is either followed by (1) another,
unrelated assignment to NextIsDereference or by (2) an early loop exit.
Found by clang's static analyzer: http://llvm.org/reports/scan-build
(While we're at it fix a typo.)
llvm-svn: 285879
Summary:
[expr.cast.static] states:
> 3. A glvalue of type “cv1 T1” can be cast to type “rvalue reference to cv2 T2” if “cv2 T2” is reference-compatible
> with “cv1 T1”. The result refers to the object or the specified base class subobject thereof. If T2 is
> an inaccessible or ambiguous base class of T1, a program that necessitates such a cast is
> ill-formed.
>
> 4. Otherwise, an expression e can be explicitly converted to a type T using a static_cast of the form static_-
> cast<T>(e) if the declaration T t(e); is well-formed, for some invented temporary variable t. [...]
Currently when checking p3 Clang will diagnose `static_cast<T&&>(e)` as invalid if the argument is not reference compatible with `T`. However I believe the correct behavior is to also check p4 in those cases. For example:
```
double y = 42;
static_cast<int&&>(y); // this should be OK. 'int&& t(y)' is well formed
```
Note that we still don't check p4 for non-reference-compatible types which are reference-related since `T&& t(e);` should never be well formed in those cases.
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D26231
llvm-svn: 285872
Previously the following code would warn on the use of "T":
template <typename T>
struct X {
typedef T *type;
};
...because nullability is /allowed/ on template parameters (because
they could be pointers). (Actually putting nullability on this use of
'T' will of course break if the argument is a non-pointer type.)
This fix doesn't handle the case where a template parameter is used
/outside/ of a typedef. That seems trickier, especially in parameter
position.
llvm-svn: 285856
This patch implements the register call calling convention, which ensures
as many values as possible are passed in registers. CodeGen changes
were committed in https://reviews.llvm.org/rL284108.
Differential Revision: https://reviews.llvm.org/D25204
llvm-svn: 285849
This commit improves the "must have C++ linkage" error diagnostics that are
emitted for C++ declarations like templates and literal operators by adding an
additional note that points to the appropriate extern "C" linkage specifier.
rdar://19021120
Differential Revision: https://reviews.llvm.org/D26189
llvm-svn: 285823
Certain OpenCL builtin functions are supposed to be executed by all threads in a work group or sub group. Such functions should not be made divergent during transformation. It makes sense to mark them with convergent attribute.
The adding of convergent attribute is based on Ettore Speziale's work and the original proposal and patch can be found at https://www.mail-archive.com/cfe-commits@lists.llvm.org/msg22271.html.
Differential Revision: https://reviews.llvm.org/D25343
llvm-svn: 285725
Unfortunately, the backend currently doesn't fold masks into the instructions correctly when they come from these shufflevectors. I'll work on that in a future commit.
llvm-svn: 285667
specification to resolve the exception specification as part of the type check,
in C++1z onwards. This is not actually part of P0012 / CWG1330 rules for when
an exception specification is "needed", but is necessary for sanity.
llvm-svn: 285663
Summary: When merging definitions with ModulesLocalVisibility enabled it's important to make deleted definitions implicitly inline, otherwise they'll be diagnosed as a redefinition.
Reviewers: silvas, manmanren, rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D26143
llvm-svn: 285655
the body of a function for the purposes of computing its storage
duration and deciding whether its initializer must be constant.
There are a number of problems in our current treatment of compound
literals. C specifies that a compound literal yields an l-value
referring to an object with either static or automatic storage
duration, depending on where it was written; in the latter case,
the literal object has a lifetime tied to the enclosing scope (much
like an ObjC block), not the enclosing full-expression. To get these
semantics fully correct in our current design, we would need to
collect compound literals on the ExprWithCleanups, just like we do
with ObjC blocks; we would probably also want to identify literals
like we do with materialized temporaries. But it gets stranger;
GCC adds compound literals to C++ as an extension, but makes them
r-values, which are generally assumed to have temporary storage
duration. Ignoring destructor ordering, the difference only matters
if the object's address escapes the full-expression, which for an
r-value can only happen with reference binding (which extends
temporaries) or array-to-pointer decay (which does not). GCC then
attempts to lock down on array-to-pointer decay in ad hoc ways.
Arguably a far superior language solution for C++ (and perhaps even
array r-values in C, which can occur in other ways) would be to
propagate lifetime extension through array-to-pointer decay, so
that initializing a pointer object to a decayed r-value array
extends the lifetime of the complete object containing the array.
But this would be a major change in semantics which arguably ought
to be blessed by the committee(s).
Anyway, I'm not fixing any of that in this patch; I did try, but
it got out of hand.
Fixes rdar://28949016.
llvm-svn: 285643
The second argument to __builtin_alloca_with_align is supposed to be in
bits, not bytes. Using alignof there would be indicative of a bug.
llvm-svn: 285609
__builtin_alloca always uses __BIGGEST_ALIGNMENT__ for the alignment of
the allocation. __builtin_alloca_with_align allows the programmer to
specify the alignment of the allocation.
This fixes PR30658.
llvm-svn: 285544
Unfortunately, the backend currently doesn't fold masks into the instructions correctly when they come from these shufflevectors. I'll work on that in a future commit.
llvm-svn: 285540
This is done so that the following compiles with no warnings:
int fn(type_10_12) __attribute__((availability(macos, introduced=10.12)));
Differential revision: https://reviews.llvm.org/D25284
llvm-svn: 285457
Summary:
In CUDA compilation, we call isInlineDefinitionExternallyVisible (via
getGVALinkageForFunction) on functions while parsing their definitions.
At the point in time when we call getGVALinkageForFunction, we haven't
yet added the body to the function, so we trip this assert. But as far
as I can tell, this is harmless.
To work around this, we add a new flag to FunctionDecl, "WillHaveBody".
There was other code that was working around the existing assert with a
really awful hack -- this change lets us get rid of that hack.
Reviewers: rsmith, tra
Subscribers: aemerson, cfe-commits
Differential Revision: https://reviews.llvm.org/D25640
llvm-svn: 285410
OpenCL disallows using variadic arguments (s6.9.e and s6.12.5 OpenCL v2.0)
apart from some exceptions:
- printf
- enqueue_kernel
This change adds error diagnostic for variadic functions but accepts printf
and any compiler internal function (which should cover __enqueue_kernel_XXX cases).
It also unifies diagnostic with block prototype and adds missing uncaught cases for blocks.
llvm-svn: 285395
This patch adds an objc_subclassing_restricted attribute into clang. This
attribute acts similarly to 'final' - Objective-C classes with this attribute
can't be subclassed. However, @interface declarations that have
objc_subclassing_restricted but don't have @implementation are allowed to
inherit other @interface declarations with objc_subclassing_restricted. This is
needed to describe the Swift class hierarchy in clang while making sure that
the Objective-C classes cannot subclass the Swift classes.
This attribute is already implemented in a fork of clang that's used for Swift
(https://github.com/apple/swift-clang) and this patch moves that code to the
upstream clang repository.
rdar://28937548
Differential Revision: https://reviews.llvm.org/D25993
llvm-svn: 285391
If we pass a header to libclang, e.g. because it's open in an editor in
an IDE, warnings about unused const vars are not useful: other files
that include the header might use those constants. So when -x *-header
is passed as command-line option, suppress this warning.
llvm-svn: 285386
The diagnostic was attempting to access the QualType of a TypeDecl by calling
TypeDecl::getTypeForDecl. However, the Type pointer stored there is lazily
loaded by functions in ASTContext. In most cases, the pointer is loaded and
this does not cause a problem. However, when more that 50 or so unknown types
are seen beforehand, this causes the Type to not be loaded, passing a null
Type to the diagnostics, leading to the crash. Using
ASTContext::getTypeDeclType will give a proper QualType for all cases.
llvm-svn: 285370
Summary: The title says it all. Additionally this patch refactors the diagnostic code into a separate function.
Reviewers: GorNishanov, rsmith
Subscribers: majnemer, mehdi_amini, cfe-commits
Differential Revision: https://reviews.llvm.org/D25292
llvm-svn: 285331
This is a misspelling of the intended !(x & A) negated bit test that happens in
practice every now and then.
I ran this on Chromium and all its dependencies, and it fired 0 times -- no
false or true positives, but it would've caught a bug in an in-progress change
that had to be caught by a Visual Studio warning instead.
https://reviews.llvm.org/D26035
llvm-svn: 285310
similarly to scalar variables.
This commit makes the -Wunused-variable warning behaviour more consistent:
Now clang won't warn for array variables where it doesn't warn for scalar
variables.
rdar://24158862
Differential Revision: https://reviews.llvm.org/D25937
llvm-svn: 285289
Sema::ActOnTag creates TagDecls for records. However, if those record
declarations are invalid, and the parser is in C++ mode, it would
silently drop the TagDecl (and leave it as "beingDefined"). The problem
is that other code (e.g. the ASTWriter) will serialize all types, and
expects them to be complete. So, leaving them open would result in
failing asserts.
Fixes PR20320
Differential Revision: http://reviews.llvm.org/D21176
llvm-svn: 285275
Summary:
This patch adds semantic checking and building of the fall-through `co_return;` statement as well as the `p.set_exception(std::current_exception())` call for handling uncaught exceptions.
The fall-through statement is built and checked according to:
> [dcl.fct.def.coroutine]/4
> The unqualified-ids return_void and return_value are looked up in the scope of class P. If
> both are found, the program is ill-formed. If the unqualified-id return_void is found, flowing
> off the end of a coroutine is equivalent to a co_return with no operand. Otherwise, flowing off
> the end of a coroutine results in undefined behavior.
Similarly the `set_exception` call is only built when that unqualified-id is found in the scope of class P.
Additionally this patch adds fall-through warnings for non-void returning coroutines. Since it's surprising undefined behavior I thought it would be important to add the warning right away.
Reviewers: majnemer, GorNishanov, rsmith
Subscribers: mehdi_amini, cfe-commits
Differential Revision: https://reviews.llvm.org/D25349
llvm-svn: 285271
If two modules contain duplicate class definitions the lookup result can contain
more than 2 elements. Sift the lookup results until we find a field decl.
It is not necessary to do ODR checks in place as they done elsewhere.
This should fix issues when compiling with libstdc++ 5.2 and 6.2.
Patch developed in collaboration with Richard Smith!
llvm-svn: 285184
This has the following ABI impact:
1) Functions whose parameter or return types are non-throwing function pointer
types have different manglings in c++1z mode from prior modes. This is
necessary because c++1z permits overloading on the noexceptness of function
pointer parameter types. A warning is issued for cases that will change
manglings in c++1z mode.
2) Functions whose parameter or return types contain instantiation-dependent
exception specifications change manglings in all modes. This is necessary
to support overloading on / SFINAE in these exception specifications, which
a careful reading of the standard indicates has essentially always been
permitted.
Note that, in order to be affected by these changes, the code in question must
specify an exception specification on a function pointer/reference type that is
written syntactically within the declaration of another function. Such
declarations are very rare, and I have so far been unable to find any code
that would be affected by this. (Note that such things will probably become
more common in C++17, since it's a lot easier to get a noexcept function type
as a function parameter / return type there.)
This change does not affect the set of symbols produced by a build of clang,
libc++, or libc++abi.
llvm-svn: 285150
The problem with the original commit was that some of Apple's headers depended
on an incorrect behaviour, this commit adds a temporary workaround until those
headers are fixed.
llvm-svn: 285098
by blocks.
Add a new warning "-Wblock-capture-autoreleasing". The warning warns
about implicitly autoreleasing out-parameters captured by blocks which
can introduce use-after-free bugs that are hard to debug.
rdar://problem/15377548
Differential Revision: https://reviews.llvm.org/D25844
llvm-svn: 285031
This reverts commit r285007 and reapply r284990, with a fix for the
opencl test that I broke. Original commit message follows:
These new builtins support a mechanism for logging OS events, using a
printf-like format string to specify the layout of data in a buffer.
The _buffer_size version of the builtin can be used to determine the size
of the buffer to allocate to hold the data, and then __builtin_os_log_format
can write data into that buffer. This implements format checking to report
mismatches between the format string and the data arguments. Most of this
code was written by Chris Willmore.
Differential Revision: https://reviews.llvm.org/D25888
llvm-svn: 285019
These new builtins support a mechanism for logging OS events, using a
printf-like format string to specify the layout of data in a buffer.
The _buffer_size version of the builtin can be used to determine the size
of the buffer to allocate to hold the data, and then __builtin_os_log_format
can write data into that buffer. This implements format checking to report
mismatches between the format string and the data arguments. Most of this
code was written by Chris Willmore.
Differential Revision: https://reviews.llvm.org/D25888
llvm-svn: 284990
Alex Lorenz