Other compilers accept invalid code here that we reject, and we need a
better error message to try to convince users that the code is really
incorrect. Consider:
class Foo {
typedef MyIterHelper<Foo> iterator;
friend class iterator;
};
Previously our wording was "elaborated type refers to a typedef".
"elaborated type" isn't widely known terminology, so the new diagnostic
says "typedef 'iterator' cannot be referenced with class specifier".
Reviewers: rsmith
Differential Revision: https://reviews.llvm.org/D25216
llvm-svn: 289259
mirror the description in the standard. Per DR1295, this means that binding a
const / rvalue reference to a bit-field no longer "binds directly", and per
P0135R1, this means that we materialize a temporary in reference binding
after adjusting cv-qualifiers and before performing a derived-to-base cast.
In C++11 onwards, this should have fixed the last case where we would
materialize a temporary of the wrong type (with a subobject adjustment inside
the MaterializeTemporaryExpr instead of outside), but we still have to deal
with that possibility in C++98, unless we want to start using xvalues to
represent materialized temporaries there too.
llvm-svn: 289250
This saves two pointers from FunctionDecl that were being used for some
rare and questionable C-only functionality. The DeclsInPrototypeScope
ArrayRef was added in r151712 in order to parse this kind of C code:
enum e {x, y};
int f(enum {y, x} n) {
return x; // should return 1, not 0
}
The challenge is that we parse 'int f(enum {y, x} n)' it its own
function prototype scope that gets popped before we build the
FunctionDecl for 'f'. The original change was doing two questionable
things:
1. Saving all tag decls introduced in prototype scope on a TU-global
Sema variable. This is problematic when you have cases like this, where
'x' and 'y' shouldn't be visible in 'f':
void f(void (*fp)(enum { x, y } e)) { /* no x */ }
This patch fixes that, so now 'f' can't see 'x', which is consistent
with GCC.
2. Storing the decls in FunctionDecl in ActOnFunctionDeclarator so that
they could be used in ActOnStartOfFunctionDef. This is just an
inefficient way to move information around. The AST lives forever, but
the list of non-parameter decls in prototype scope is short lived.
Moving these things to the Declarator solves both of these issues.
Reviewers: rsmith
Subscribers: jmolloy, cfe-commits
Differential Revision: https://reviews.llvm.org/D27279
llvm-svn: 289225
This commit ensures that the switch warning "case value not in enumerated type"
isn't shown for opaque enums. We don't know the actual list of values in opaque
enums, so that warning is incorrect.
rdar://29230764
Differential Revision: https://reviews.llvm.org/D27299
llvm-svn: 289055
We continue to support dynamic exception specifications in C++1z as an
extension, but produce an error-by-default warning when we encounter one. This
allows users to opt back into the feature with a warning flag, and implicitly
opts system headers back into the feature should they happen to use it.
There is one semantic change implied by P0003R5 but not implemented here:
violating a throw() exception specification should now call std::terminate
directly instead of calling std::unexpected(), but since P0003R5 also removes
std::unexpected() and std::set_unexpected, and the default unexpected handler
calls std::terminate(), a conforming C++1z program cannot tell that we are
still calling it. The upside of this strategy is perfect backwards
compatibility; the downside is that we don't get the more efficient 'noexcept'
codegen for 'throw()'.
llvm-svn: 289019
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
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
arguments from a declaration; despite what the standard says, this form of
deduction should not be considering exception specifications.
llvm-svn: 288301
specifications in this mode in C++17, since they're part of the function type,
so check and diagnose them like we would if exceptions were enabled.
Better ideas welcome.
llvm-svn: 288220
Since r274049, for an inheriting constructor declaration, the name of the using
declaration (and using shadow declaration comes from the using declaration) is
the name of a derived class, not the base class (line 8225-8232 of
lib/Sema/SemaDeclCXX.cpp in https://reviews.llvm.org/rL274049). Because of
this, name-based lookup performed inside Sema::LookupConstructors returns not
only CXXConstructorDecls but also Using(Shadow)Decls, which results assertion
failure reported in PR29087.
Patch by Taewook Oh, thanks!
Differential Revision: https://reviews.llvm.org/D23765
llvm-svn: 287999
Summary:
We don't need a side table in ASTContext to hold CXXDefaultArgExprs. The
important part of building the CXXDefaultArgExprs was to ODR use the
default argument expressions, not to make AST nodes. Refactor the code
to only check the default argument, and remove the side table in
ASTContext which wasn't being serialized.
Fixes PR31121
Reviewers: thakis, rsmith, majnemer
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D27007
llvm-svn: 287774
with __unknown_anytype return type.
When the following code is compiled, Sema infers that the type of
__unknown_anytype is double:
extern __unknown_anytype func();
double *d = (double*)&func();
This triggers an assert in CodeGenFunction::EmitCallExprLValue because
it doesn't expect to see a call to a function with a non-reference
scalar return type.
This commit prevents the assert by making VisitUnaryAddrOf error out if
the address-of operator is applied to a call to a function with
__unknown_anytype return type.
rdar://problem/20287610
Differential revision: https://reviews.llvm.org/D26808
llvm-svn: 287410
During template instantiation, we currently fall back to just calling
Sema::SubstExpr for enable_if attributes that aren't value-dependent or
type-dependent. Since Sema::SubstExpr strips off any implicit casts
we've added to an expression, it's possible that this behavior will
leave us with an enable_if condition that's just a DeclRefExpr.
Conditions like that deeply confuse Sema::CheckEnableIf.
llvm-svn: 287187
Summary:
Add a warning when assigning enums to bitfields without an explicit
unsigned underlying type. This is to prevent problems with MSVC
compatibility, since the Microsoft ABI defaults to storing enums with a
signed type, causing inconsistencies with saving to/reading from
bitfields.
Also disabled the warning in the dr0xx.cpp test which throws the error,
and added a test for the warning.
The warning can be disabled with -Wno-signed-enum-bitfield.
Patch by Sasha Bermeister!
Reviewers: rnk, aaron.ballman
Subscribers: mehdi_amini, aaron.ballman, cfe-commits, thakis, dcheng
Differential Revision: https://reviews.llvm.org/D24289
llvm-svn: 287177
Before:
<stdin>:3:3: error: no matching member function for call to 'bar'
Foo().bar();
^
After:
<stdin>:3:9: error: no matching member function for call to 'bar'
Foo().bar();
^
llvm-svn: 287154
Instead of always displaying the mangled name, try to do better
and get something closer to regular functions.
Recommit r287039 (that was reverted in r287039) with a tweak to
be more generic, and test fixes!
Differential Revision: https://reviews.llvm.org/D26522
llvm-svn: 287085
Only look for a variable's value in the constant expression evaluation activation frame, if the variable was indeed declared in that frame, otherwise it might be a constant expression and be usable within a nested local scope or emit an error.
void f(char c) {
struct X {
static constexpr char f() {
return c; // error gracefully here as opposed to crashing.
}
};
int I = X::f();
}
llvm-svn: 286748
If initializer contains parentheses around braced list where it is not allowed,
as in construct int({0}), clang issued message like `functional-style cast
from 'void' to 'int' is not allowed`, which does not help much. Both gcc and
msvc issue message `list-initializer for non-class type must not be
parenthesized`, which is more descriptive. This change implements similar
message for clang.
Differential Revision: https://reviews.llvm.org/D25816
llvm-svn: 286721
Since array parameters decay to pointers, '_Nullable' and friends
should be available for use there as well. This is especially
important for parameters that are typedefs of arrays. The unsugared
syntax for this follows the syntax for 'static'-sized arrays in C:
void test(int values[_Nullable]);
This syntax was previously accepted but the '_Nullable' (and any other
attributes) were silently discarded. However, applying '_Nullable' to
a typedef was previously rejected and is now accepted; therefore, it
may be necessary to test for the presence of this feature:
#if __has_feature(nullability_on_arrays)
One important change here is that DecayedTypes don't always
immediately contain PointerTypes anymore; they may contain an
AttributedType instead. This only affected one place in-tree, so I
would guess it's not likely to cause problems elsewhere.
This commit does not change -Wnullability-completeness just yet. I
want to think about whether it's worth doing something special to
avoid breaking existing clients that compile with -Werror. It also
doesn't change '#pragma clang assume_nonnull' behavior, which
currently treats the following two declarations as equivalent:
#pragma clang assume_nonnull begin
void test(void *pointers[]);
#pragma clang assume_nonnull end
void test(void * _Nonnull pointers[]);
This is not the desired behavior, but changing it would break
backwards-compatibility. Most likely the best answer is going to be
adding a new warning.
Part of rdar://problem/25846421
llvm-svn: 286519
aren't captured by lambdas with a default capture specifier
This commit is a follow-up to r286354. It avoids the -Wshadow warning for
variables which shadow variables that aren't captured by lambdas with a default
capture specifier. It provides an additional note that points to location of
the capture.
The old behaviour is preserved with -Wshadow-all or -Wshadow-uncaptured-local.
rdar://14984176
Differential Revision: https://reviews.llvm.org/D26448
llvm-svn: 286465
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
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
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
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
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
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 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
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
Reid Kleckner