Commit Graph

157 Commits

Author SHA1 Message Date
Richard Smith 700537cddf If parsing a trailing-return-type fails, don't pretend we didn't have one at
all. Suppresses follow-on errors mentioned in PR13074.

llvm-svn: 158348
2012-06-12 01:51:59 +00:00
Richard Smith b58000950e Fix PR13052 properly, by performing special member lookup to determine whether
an explicitly-defaulted default constructor would be constexpr. This is
necessary in weird (but well-formed) cases where a class has more than one copy
or move constructor.

Cleanup of now-unused parts of CXXRecordDecl to follow.

llvm-svn: 158289
2012-06-10 05:43:50 +00:00
Richard Smith 7d847b1ec1 When diagnosing inaccessible temporary destructors in decltype expressions, use
the correct type and the correct source location in the diagnostic. Spotted by
Johannes Schaub!

llvm-svn: 156654
2012-05-11 22:20:10 +00:00
Richard Smith 2f07ad5a70 Push the knowledge that we are parsing a type-id/type-name further into the
parser, and use it to emit better diagnostics in cases where an identifer
can't be looked up as a type name.

llvm-svn: 156508
2012-05-09 20:55:26 +00:00
Richard Smith 7bdcc4a9da Disambiguation of '[[':
* In C++11, '[[' is ill-formed unless it starts an attribute-specifier. Reject
   array sizes and array indexes which begin with a lambda-expression. Recover by
   parsing the lambda as a lambda.
 * In Objective-C++11, either '[' could be the start of a message-send.
   Fully disambiguate this case: it turns out that the grammars of message-sends,
   lambdas and attributes do not actually overlap. Accept any occurrence of '[['
   where either '[' starts a message send, but reject a lambda in an array index
   just like in C++11 mode.

Implement a couple of changes to the attribute wording which occurred after our
attributes implementation landed:
 * In a function-declaration, the attributes go after the exception specification,
   not after the right paren.
 * A reference type can have attributes applied.
 * An 'identifier' in an attribute can also be a keyword. Support for alternative
   tokens (iso646 keywords) in attributes to follow.

And some bug fixes:
 * Parse attributes after declarator-ids, even if they are not simple identifiers.
 * Do not accept attributes after a parenthesized declarator.
 * Accept attributes after an array size in a new-type-id.
 * Partially disamiguate 'delete' followed by a lambda. More work is required
   here for the case where the lambda-introducer is '[]'.

llvm-svn: 154369
2012-04-10 01:32:12 +00:00
Richard Smith d8b8effa6e Temporary workaround for bug#12457: turn the 'constexpr function never produces
a constant expression' error into a DefaultError ExtWarn, so that it can be
disabled and is suppressed in system headers. libstdc++4.7 contains some such
functions which we currently can't evaluate as constant expressions.

llvm-svn: 154115
2012-04-05 18:57:10 +00:00
Richard Smith 05afe5e084 Fix PR10447: lazily building name lookup tables for DeclContexts was broken.
The deferred lookup table building step couldn't accurately tell which Decls
should be included in the lookup table, and consequently built different tables
in some cases.

Fix this by removing lazy building of DeclContext name lookup tables. In
practice, the laziness was frequently not worthwhile in C++, because we
performed lookup into most DeclContexts. In C, it had a bit more value,
since there is no qualified lookup.

In the place of lazy lookup table building, we simply don't build lookup tables
for function DeclContexts at all. Such name lookup tables are not useful, since
they don't capture the scoping information required to correctly perform name
lookup in a function scope.

The resulting performance delta is within the noise on my testing, but appears
to be a very slight win for C++ and a very slight loss for C. The C performance
can probably be recovered (if it is a measurable problem) by avoiding building
the lookup table for the translation unit.

llvm-svn: 152608
2012-03-13 03:12:56 +00:00
Richard Smith bfdb108fc5 Fix parsing of trailing-return-type. Types are syntactically prohibited from
being defined here: [] () -> struct S {} does not define struct S.

In passing, implement DR1318 (syntactic disambiguation of 'final').

llvm-svn: 152551
2012-03-12 08:56:40 +00:00
Richard Smith c5b0552055 Fix parsing of type-specifier-seq's. Types are syntactically allowed to be
defined here, but not semantically, so

  new struct S {};

is always ill-formed, even if there is a struct S in scope.

We also had a couple of bugs in ParseOptionalTypeSpecifier caused by it being
under-loved (due to it only being used in a few places) so merge it into
ParseDeclarationSpecifiers with a new DeclSpecContext. To avoid regressing, this
required improving ParseDeclarationSpecifiers' diagnostics in some cases. This
also required teaching ParseSpecifierQualifierList about constexpr... which
incidentally fixes an issue where we'd allow the constexpr specifier in other
bad places.

llvm-svn: 152549
2012-03-12 07:56:15 +00:00
Richard Smith f506eaf36d static_assert: Allow any string-literal as the message, not just a character
string literal, and adjust the diagnostic code to match. This also causes us
to escape any control characters in the message.

llvm-svn: 152069
2012-03-05 23:20:05 +00:00
Richard Smith 2a15b74605 Accept braced-init-lists in conditions, and, in passing, dramatically improve
the diagnostic for using a parenthesized direct-initializer in a condition.

llvm-svn: 151137
2012-02-22 06:49:09 +00:00
Richard Smith fd555f6b1f Implement C++11 [expr.call]p11: If the operand to a decltype-specifier is a
function call (or a comma expression with a function call on its right-hand
side), possibly parenthesized, then the return type is not required to be
complete and a temporary is not bound. Other subexpressions inside a decltype
expression do not get this treatment.

This is implemented by deferring the relevant checks for all calls immediately
within a decltype expression, then, when the expression is fully-parsed,
checking the relevant constraints and stripping off any top-level temporary
binding.

Deferring the completion of the return type exposed a bug in overload
resolution where completion of the argument types was not attempted, which
is also fixed by this change.

llvm-svn: 151117
2012-02-22 02:04:18 +00:00
Richard Smith 5b8b3db5c9 Fix a constexpr FIXME: When implicitly instantiating the primary template for an
explicit specialization of a function template, mark the instantiation as
constexpr if the specialization is, rather than requiring them to match.

llvm-svn: 151001
2012-02-20 23:28:05 +00:00
Richard Smith 17100bad0a constexpr tidyups:
* Fix bug when determining whether && / || are potential constant expressions
  * Try harder when determining whether ?: is a potential constant expression
  * Produce a diagnostic on sizeof(VLA) to provide a better source location

llvm-svn: 150657
2012-02-16 02:46:34 +00:00
Richard Smith 3607ffee5c Update constexpr implementation to match CWG's chosen approach for core issues
1358, 1360, 1452 and 1453.
 - Instantiations of constexpr functions are always constexpr. This removes the
   need for separate declaration/definition checking, which is now gone.
 - This makes it possible for a constexpr function to be virtual, if they are
   only dependently virtual. Virtual calls to such functions are not constant
   expressions.
 - Likewise, it's now possible for a literal type to have virtual base classes.
   A constexpr constructor for such a type cannot actually produce a constant
   expression, though, so add a special-case diagnostic for a constructor call
   to such a type rather than trying to evaluate it.
 - Classes with trivial default constructors (for which value initialization can
   produce a fully-initialized value) are considered literal types.
 - Classes with volatile members are not literal types.
 - constexpr constructors can be members of non-literal types. We do not yet use
   static initialization for global objects constructed in this way.

llvm-svn: 150359
2012-02-13 03:54:03 +00:00
Douglas Gregor e096a35518 Implement the standard decltype() semantics described in C++11
[dcl.type.simple]p4, which treats all xvalues as returning T&&. We had
previously implemented a pre-standard variant of decltype() that
doesn't cope with, e.g., static_ast<T&&>(e) very well.

llvm-svn: 150348
2012-02-12 18:57:57 +00:00
Richard Smith 63168c7533 PR11684, core issue 1417:
o Correct the handling of the restrictions on usage of cv-qualified and
  ref-qualified function types.
o Fix a bug where such types were rejected in template type parameter default
  arguments, due to such arguments not being treated as a template type arg
  context.
o Remove the ExtWarn for usage of such types as template arguments; that was
  a standard defect, not a GCC extension.
o Improve the wording and unify the code for diagnosing cv-qualifiers with the
  code for diagnosing ref-qualifiers.

llvm-svn: 150244
2012-02-10 11:05:11 +00:00
Richard Smith 4d59eebb49 DR1359: A constexpr constructor does not need to initialize an empty struct or
empty union. This still rejects anonymous member structs or unions which only
contain such empty class types, pending standard wording defining exactly what
an empty class type is.

llvm-svn: 150157
2012-02-09 06:40:58 +00:00
Richard Smith 3c7ad4e01b Add more testing for r149776.
llvm-svn: 150061
2012-02-08 06:41:34 +00:00
Richard Smith 2de5a939e2 constexpr: Implement DR1358: An instantiation of a constexpr function which
can't produce a constant expression is not ill-formed (so long as some
instantiation of that function can produce a constant expression).

llvm-svn: 149802
2012-02-05 02:30:54 +00:00
Richard Smith 84f6dcf2b5 constexpr:
* support the gcc __builtin_constant_p() ? ... : ... folding hack in C++11
  * check for unspecified values in pointer comparisons and pointer subtractions

llvm-svn: 149578
2012-02-02 01:16:57 +00:00
Richard Smith 0287910521 constexpr: Unlike other incomplete types, 'void' cannot possibly be completed as
a literal type. Disallow it as the return type of a constexpr function
declaration.

llvm-svn: 149469
2012-02-01 04:40:02 +00:00
Richard Smith 253c2a390a constexpr: Implement the [dcl.constexpr]p5 check for whether a constexpr
function definition can produce a constant expression. This also provides the
last few checks for [dcl.constexpr]p3 and [dcl.constexpr]p4.

llvm-svn: 149108
2012-01-27 01:14:48 +00:00
Sebastian Redl 09edce0400 Minor fixups for auto deduction of initializer lists.
Fix some review comments.
Add a test for deduction when std::initializer_list isn't available yet.
Fix redundant error messages. This fixes and outstanding FIXME too.

llvm-svn: 148735
2012-01-23 22:09:39 +00:00
Richard Smith 7971b69f74 PR11754: Reject non-static constexpr member functions in classes with virtual
base classes.

llvm-svn: 148094
2012-01-13 04:54:00 +00:00
Eli Friedman c8002429e5 constexpr is allowed on static member functions of non-literal classes. Per report on cfe-dev.
llvm-svn: 148090
2012-01-13 02:31:53 +00:00
Richard Smith 8d06f42448 Improve 0-argument -Wvexing-parse diagnostic by adding notes with fix-its:
- If the declarator is at the start of a line, and the previous line contained
   another declarator and ended with a comma, then that comma was probably a
   typo for a semicolon:

   int n = 0, m = 1, l = 2, // k = 5;
   myImportantFunctionCall(); // oops!

 - If removing the parentheses would correctly initialize the object, then
   produce a note suggesting that fix.

 - Otherwise, if there is a simple initializer we can suggest which performs
   value-initialization, then provide a note suggesting a correction to that
   initializer.

Sema::Declarator now tracks the location of the comma prior to the declarator in
the declaration, if there is one, to facilitate providing the note. The code to
determine an appropriate initializer from the -Wuninitialized warning has been
factored out to allow use in both that and -Wvexing-parse.

llvm-svn: 148072
2012-01-12 23:53:29 +00:00
Richard Smith 0f8ee22655 Update C++11 scoped enumeration support to match the final proposal:
- reject definitions of enums within friend declarations
 - require 'enum', not 'enum class', for non-declaring references to scoped
   enumerations

llvm-svn: 147824
2012-01-10 01:33:14 +00:00
Richard Smith b3851f5ca1 David Blaikie and Chandler would like us to diagnose
int f();

in function scopes under -Wvexing-parse, so now we do.

llvm-svn: 147649
2012-01-06 02:30:50 +00:00
Richard Smith d069d2f6ac Tweak to r147599 for PR10828: Move the check from the parser into sema, and use
the Semantic Powers to only warn on class types (or dependent types), where the
constructor or destructor could do something interesting.

llvm-svn: 147642
2012-01-06 01:31:20 +00:00
Richard Smith 69f90dce49 PR10828: Produce a warning when a no-arguments function is declared in block
scope, when no other indication is provided that the user intended to declare a
function rather than a variable.

Remove some false positives from the existing 'parentheses disambiguated as a
function' warning by suppressing it when the declaration is marked as 'typedef'
or 'extern'.

Add a new warning group -Wvexing-parse containing both of these warnings.

The new warning is enabled by default; despite a number of false positives (and
one bug) in clang's test-suite, I have only found genuine bugs with it when
running it over a significant quantity of real C++ code.

llvm-svn: 147599
2012-01-05 04:12:21 +00:00
Richard Smith cc36f698af PR11614: Mark defaulted special constructors as constexpr if their implicit
definition would satisfy the constexpr requirements.

llvm-svn: 147128
2011-12-22 02:22:31 +00:00
Richard Smith f2b681b4d8 constexpr: diagnostic improvements for invalid lvalue-to-rvalue conversions in
constant expressions.

llvm-svn: 147035
2011-12-21 05:04:46 +00:00
Richard Smith 242ad89a15 C++11 half of r147023: In C++11, additionally eagerly instantiate:
- constexpr function template instantiations
 - variables of reference type
 - constexpr variables

llvm-svn: 147031
2011-12-21 02:55:12 +00:00
Richard Smith d0b4dd656d constexpr handling improvements. Produce detailed diagnostics when a 'constexpr'
variable is initialized by a non-constant expression, and pass in the variable
being declared so that earlier-initialized fields' values can be used.

Rearrange VarDecl init evaluation to make this possible, and in so doing fix a
long-standing issue in our C++ constant expression handling, where we would
mishandle cases like:

  extern const int a;
  const int n = a;
  const int a = 5;
  int arr[n];

Here, n is not initialized by a constant expression, so can't be used in an ICE,
even though the initialization expression would be an ICE if it appeared later
in the TU. This requires computing whether the initializer is an ICE eagerly,
and saving that information in PCH files.

llvm-svn: 146856
2011-12-19 06:19:21 +00:00
Richard Trieu 553b2b2e5d Modify how the -verify flag works. Currently, the verification string and
diagnostic message are compared.  If either is a substring of the other, then
no error is given.  This gives rise to an unexpected case:

  // expect-error{{candidate function has different number of parameters}}

will match the following error messages from Clang:

  candidate function has different number of parameters (expected 1 but has 2)
  candidate function has different number of parameters

It will also match these other error messages:

  candidate function
  function has different number of parameters
  number of parameters

This patch will change so that the verification string must be a substring of
the diagnostic message before accepting.  Also, all the failing tests from this
change have been corrected.  Some stats from this cleanup:

87 - removed extra spaces around verification strings
70 - wording updates to diagnostics
40 - extra leading or trailing characters (typos, unmatched parens or quotes)
35 - diagnostic level was included (error:, warning:, or note:)
18 - flag name put in the warning (-Wprotocol)

llvm-svn: 146619
2011-12-15 00:38:15 +00:00
John McCall d5c98ae695 Resolve placeholder expressions before trying to deduce
'auto'.  Introduce a convenience method to make this a bit
easier, and use it elsewhere.

llvm-svn: 144605
2011-11-15 01:35:18 +00:00
Richard Smith ce40ad677e Represent an APValue based on a Decl as that Decl, rather than a DeclRefExpr
or MemberExpr which refers to it. As a side-effect, MemberExprs which refer to
static member functions and static data members are now emitted as constant
expressions.

llvm-svn: 144468
2011-11-12 22:28:03 +00:00
Richard Smith d62306a481 Constant expression evaluation: support for evaluation of structs and unions of
literal types, as well as derived-to-base casts for lvalues and
derived-to-virtual-base casts.

llvm-svn: 144265
2011-11-10 06:34:14 +00:00
Richard Smith eda3c84698 constexpr: static data members declared constexpr are required to have an
initializer; all other constexpr variables are merely required to be
initialized. In particular, a user-provided constexpr default constructor can be
used for such initialization.

llvm-svn: 144028
2011-11-07 22:16:17 +00:00
Richard Smith 53cafabac0 Add test missed from r143234.
llvm-svn: 143257
2011-10-29 00:03:08 +00:00
Douglas Gregor baabbb779d Undo unnecessary change
llvm-svn: 142907
2011-10-25 03:47:25 +00:00
Douglas Gregor ab6bc1d13e Make the -Wc++11-compat warnings ignored by default, so we don't break
valid C++98/03 code. However, add these warnings to -Wall, for those
who obviously already like clean code.

llvm-svn: 142903
2011-10-25 03:07:45 +00:00
Peter Collingbourne e109a2ca59 Attach class template attributes to the templated CXXRecordDecl,
instead of silently discarding them.

As a side effect, this improves diagnostics for constexpr class
templates slightly.

llvm-svn: 142755
2011-10-23 17:07:16 +00:00
Peter Collingbourne 99eddc3d92 Permit auto SCS on parameter declarations, C++03 [dcl.stc]p2
llvm-svn: 142649
2011-10-21 11:55:09 +00:00
David Blaikie cc5f8f0d9e Switch to the C++11 warning flags in tests.
Patch by Ahmed Charles!

llvm-svn: 142340
2011-10-18 05:54:07 +00:00
Richard Smith 9ca5c42582 Update all tests other than Driver/std.cpp to use -std=c++11 rather than
-std=c++0x. Patch by Ahmed Charles!

llvm-svn: 141900
2011-10-13 22:29:44 +00:00
Douglas Gregor 205d044552 Switch diagnostic text from "C++0x" over to "C++11".
We'd also like for "C++11" or "c++11" to be used for the warning
groups, but without removing the old warning flags. Patches welcome;
I've run out of time to work on this today.

llvm-svn: 141801
2011-10-12 19:26:40 +00:00
Richard Smith f368fb40df constexpr: Disable checking of constructor member initializer lists for
constexpr constructor templates. Such checking is optional, and currently hard
to get right since clang doesn't generate implicit member initializers until
instantiation (even for non-dependent members).

This is needed for clang to accept libstdc++ from g++4.6 in c++0x mode.

llvm-svn: 141547
2011-10-10 16:38:04 +00:00
Douglas Gregor bb64afcc39 Diagnose attempts to declare a non-static data member with a
non-identifier name. Fixes PR10839.

llvm-svn: 141513
2011-10-09 18:55:59 +00:00