Commit Graph

19 Commits

Author SHA1 Message Date
Haojian Wu 62dea6e9be Revert "[AST] Build recovery expressions by default for C++."
This reverts commit 0788acbccb.
This reverts commit c2d7a1f79cedfc9fcb518596aa839da4de0adb69:  Revert "[clangd] Add test for FindTarget+RecoveryExpr (which already works). NFC"

It causes a crash on invalid code:

class X {
  decltype(unresolved()) foo;
};
constexpr int s = sizeof(X);
2020-03-26 16:25:32 +01:00
Haojian Wu 0788acbccb [AST] Build recovery expressions by default for C++.
Update the existing tests.

Reviewers: sammccall

Subscribers: cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D76696
2020-03-25 09:00:48 +01:00
Richard Smith 5030928d60 [c++20] Implement semantic restrictions for C++20 designated
initializers.

This has some interesting interactions with our existing extensions to
support C99 designated initializers as an extension in C++. Those are
resolved as follows:

 * We continue to permit the full breadth of C99 designated initializers
   in C++, with the exception that we disallow a partial overwrite of an
   initializer with a non-trivially-destructible type. (Full overwrite
   is OK, because we won't run the first initializer at all.)

 * The C99 extensions are disallowed in SFINAE contexts and during
   overload resolution, where they could change the meaning of valid
   programs.

 * C++20 disallows reordering of initializers. We only check for that for
   the simple cases that the C++20 rules permit (designators of the form
   '.field_name =' and continue to allow reordering in other cases).
   It would be nice to improve this behavior in future.

 * All C99 designated initializer extensions produce a warning by
   default in C++20 mode. People are going to learn the C++ rules based
   on what Clang diagnoses, so it's important we diagnose these properly
   by default.

 * In C++ <= 17, we apply the C++20 rules rather than the C99 rules, and
   so still diagnose C99 extensions as described above. We continue to
   accept designated C++20-compatible initializers in C++ <= 17 silently
   by default (but naturally still reject under -pedantic-errors).

This is not a complete implementation of P0329R4. In particular, that
paper introduces new non-C99-compatible syntax { .field { init } }, and
we do not support that yet.

This is based on a previous patch by Don Hinton, though I've made
substantial changes when addressing the above interactions.

Differential Revision: https://reviews.llvm.org/D59754

llvm-svn: 370544
2019-08-30 22:52:55 +00:00
Richard Smith 5159bbad8b PR38627: Fix handling of exception specification adjustment for
destructors.

We previously tried to patch up the exception specification after
completing the class, which went wrong when the exception specification
was needed within the class body (in particular, by a friend
redeclaration of the destructor in a nested class). We now mark the
destructor as having a not-yet-computed exception specification
immediately after creating it.

This requires delaying various checks against the exception
specification (where we'd previously have just got the wrong exception
specification, and now find we have an exception specification that we
can't compute yet) when those checks fire while the class is being
defined.

This also exposed an issue that we were missing a CodeSynthesisContext
for computation of exception specifications (otherwise we'd fail to make
the module containing the definition of the class visible when computing
its members' exception specs). Adding that incidentally also gives us a
diagnostic quality improvement.

This has also exposed an pre-existing problem: making the exception
specification evaluation context a non-SFINAE context (as it should be)
results in a bootstrap failure; PR38850 filed for this.

llvm-svn: 341499
2018-09-05 22:30:37 +00:00
Richard Smith f3b4ca89e7 PR36055: fix computation of *-dependence in nested initializer lists.
When we synthesize an implicit inner initializer list when analyzing an outer
initializer list, we add it to the outer list immediately, and then fill in the
inner list. This gives the outer list no chance to update its *-dependence bits
with those of the completed inner list. To fix this, re-add the inner list to
the outer list once it's completed.

Note that we do not recompute the *-dependence bits from scratch when we
complete an outer list; this would give the wrong result for the case where a
designated initializer overwrites a dependent initializer with a non-dependent
one. The resulting list in that case should still be dependent, even though all
traces of the dependence were removed from the semantic form.

llvm-svn: 324537
2018-02-07 22:25:16 +00:00
Richard Smith d6a150829b PR23135: Don't instantiate constexpr functions referenced in unevaluated operands where possible.
This implements something like the current direction of DR1581: we use a narrow
syntactic check to determine the set of places where a constant expression
could be evaluated, and only instantiate a constexpr function or variable if
it's referenced in one of those contexts, or is odr-used.

It's not yet clear whether this is the right set of syntactic locations; we
currently consider all contexts within templates that would result in odr-uses
after instantiation, and contexts within list-initialization (narrowing
conversions take another victim...), as requiring instantiation. We could in
principle restrict the former cases more (only const integral / reference
variable initializers, and contexts in which a constant expression is required,
perhaps). However, this is sufficient to allow us to accept libstdc++ code,
which relies on GCC's behavior (which appears to be somewhat similar to this
approach).

llvm-svn: 291318
2017-01-07 00:48:55 +00:00
Reid Kleckner d60b82f93e Handle use of default member initializers before end of outermost class
Specifically, when we have this situation:
  struct A {
    template <typename T> struct B {
      int m1 = sizeof(A);
    };
    B<int> m2;
  };

We can't parse m1's initializer eagerly because we need A to be
complete.  Therefore we wait until the end of A's class scope to parse
it. However, we can trigger instantiation of B before the end of A,
which will attempt to instantiate the field decls eagerly, and it would
build a bad field decl instantiation that said it had an initializer but
actually lacked one.

Fixed by deferring instantiation of default member initializers until
they are needed during constructor analysis. This addresses a long
standing FIXME in the code.

Fixes PR19195.

Reviewed By: rsmith

Differential Revision: http://reviews.llvm.org/D5690

llvm-svn: 222192
2014-11-17 23:36:45 +00:00
Richard Smith 3b717527f4 Return statements are initialization; don't forget to revert the initializer to
its syntactic form before re-analyzing it during template instantiation.

llvm-svn: 216224
2014-08-21 20:51:13 +00:00
Eli Friedman 89fe0d5842 Properly track l-paren of a CXXFucntionalCastExpr.
In addition to storing more useful information in the AST, this
fixes a semantic check in template instantiation which checks whether
the l-paren location is valid.

Fixes PR16903.

llvm-svn: 188495
2013-08-15 22:02:56 +00:00
Richard Smith 44ecdbdc61 Improve 'failed template argument deduction' diagnostic for the case where we
have a direct mismatch between some component of the template and some
component of the argument. The diagnostic now says what the mismatch was, but
doesn't yet say which part of the template doesn't match.

llvm-svn: 174039
2013-01-31 05:19:49 +00:00
Eli Friedman 07bab73c7f Using CanQualType::getAs<ArrayType> is unsafe; fix the code currently using it,
and make sure additional uses don't get introduced.  <rdar://problem/12858424>.

llvm-svn: 170081
2012-12-13 01:43:21 +00:00
Richard Smith 2b013185f8 PR13064: Store whether an in-class initializer uses direct or copy
initialization, and use that information to produce the right kind of
initialization during template instantiation.

llvm-svn: 158288
2012-06-10 03:12:00 +00:00
Douglas Gregor 28de7a9a1e Improve the instantiation of static data members in
Sema::RequireCompleteExprType() a bit more, setting the point of
instantiation if needed, and skipping explicit specializations entirely.

llvm-svn: 132547
2011-06-03 14:28:43 +00:00
Douglas Gregor 57d4f972b7 When performing template argument deduction given a function argument
of incomplete array type, attempt to complete the array type. This was
made much easier by Chandler's addition of RequireCompleteExprType(),
which I've tweaked (slightly) to improve the consistency of the
DeclRefExpr. Fixes PR7985.

llvm-svn: 132530
2011-06-03 03:35:07 +00:00
Chandler Carruth 7c430c0ec2 Enhance Clang to start instantiating static data member definitions
within class templates when they are necessary to complete the type of
the member. The canonical example is code like:

  template <typename T> struct S {
    static const int arr[];
    static const int x;
    static int f();
  };

  template <typename T> const int S<T>::arr[] = { 1, 2, 3 };
  template <typename T> const int S<T>::x = sizeof(arr) / sizeof(arr[0]);
  template <typename T> int S<T>::f() { return x; }

  int x = S<int>::f();

We need to instantiate S<T>::arr's definition to pick up its initializer
and complete the array type. This involves new code to specially handle
completing the type of an expression where the type alone is
insufficient. It also requires *updating* the expression with the newly
completed type. Fortunately, all the other infrastructure is already in
Clang to do the instantiation, do the completion, and prune out the
unused bits of code that result from this instantiation.

This addresses the initial bug in PR10001, and will be a step to
fleshing out other cases where we need to work harder to complete an
expression's type. Who knew we still had missing C++03 "features"?

llvm-svn: 132172
2011-05-27 01:33:31 +00:00
Douglas Gregor dc76403cc1 When pulling apart an initializer that involves a CXXConstructExpr, do
not pick apart a CXXTemporaryObjectExpr because such an object
construction was explicitly written in the source code. Fixes PR6657.

llvm-svn: 99427
2010-03-24 21:22:47 +00:00
Douglas Gregor 9bc6b7fc53 Use CXXTemporaryObjectExpr for explicitly-constructed temporaries. We
used to do this, but it got lost when we switched functional-style
cast syntax over to using the new initialization code. Fixes PR6457.

llvm-svn: 97568
2010-03-02 17:18:33 +00:00
Daniel Dunbar 8fbe78f6fc Update tests to use %clang_cc1 instead of 'clang-cc' or 'clang -cc1'.
- This is designed to make it obvious that %clang_cc1 is a "test variable"
   which is substituted. It is '%clang_cc1' instead of '%clang -cc1' because it
   can be useful to redefine what gets run as 'clang -cc1' (for example, to set
   a default target).

llvm-svn: 91446
2009-12-15 20:14:24 +00:00
Douglas Gregor 402250f2f9 Implement support for C++ direct initializers that involve dependent
types or type-dependent expressions.

llvm-svn: 80143
2009-08-26 21:14:46 +00:00