Commit Graph

164 Commits

Author SHA1 Message Date
Richard Smith 0a088ead85 Improve diagnostics for missing import / #include of module.
Fix a few bugs where we would fail to properly determine header to
module correspondence when determining whether to suggest a #include or
import, and suggest a #include more often in language modes where there
is no import syntax. Generally, if the target is in a header with
include guards or #pragma once, we should suggest either #including or
importing that header, and not importing a module that happens to
textually include it.

In passing, improve the notes we attach to the corresponding
diagnostics: calling an entity that we couldn't see "previous" is
confusing.
2020-04-28 18:41:14 -07:00
Fangrui Song d0d076fed9 [Driver] Flip the CC1 default of -fdiagnostics-show-option
The driver enables -fdiagnostics-show-option by default, so flip the CC1
default to reduce the lengths of common CC1 command lines.

This change also makes ParseDiagnosticArgs() consistently enable
-fdiagnostics-show-option by default.
2020-03-31 21:59:27 -07:00
Richard Smith 0c42539df3 Improve error recovery from missing '>' in template argument list.
Produce the conventional "to match this '<'" note, so that the user
knows why we expected a '>', and properly handle '>>' in C++11 onwards.
2020-03-27 18:59:01 -07:00
Richard Smith 24ad121582 Add -std=c++20 flag, replace C++2a with C++20 throughout the Clang
user interface and documentation, and update __cplusplus for C++20.

WG21 considers the C++20 standard to be finished (even though it still
has some more steps to pass through in the ISO process).

The old flag names are accepted for compatibility, as usual, and we
still have lots of references to C++2a in comments and identifiers;
those can be cleaned up separately.
2020-02-18 16:16:37 -08:00
Richard Smith 2519554134 When diagnosing the lack of a viable conversion function, also list
explicit functions that are not candidates.

It's not always obvious that the reason a conversion was not possible is
because the function you wanted to call is 'explicit', so explicitly say
if that's the case.

It would be nice to rank the explicit candidates higher in the
diagnostic if an implicit conversion sequence exists for their
arguments, but unfortunately we can't determine that without potentially
triggering non-immediate-context errors that we're not permitted to
produce.
2020-01-09 15:15:02 -08:00
Richard Smith 24cdcadcc5 C++ DR712 and others: handle non-odr-use resulting from an lvalue-to-rvalue conversion applied to a member access or similar not-quite-trivial lvalue expression.
Summary:
When a variable is named in a context where we can't directly emit a
reference to it (because we don't know for sure that it's going to be
defined, or it's from an enclosing function and not captured, or the
reference might not "work" for some reason), we emit a copy of the
variable as a global and use that for the known-to-be-read-only access.

This reinstates r363295, reverted in r363352, with a fix for PR42276:
we now produce a proper name for a non-odr-use reference to a static
constexpr data member. The name <mangled-name>.const is used in that
case; such names are reserved to the implementation for cases such as
this and should demangle nicely.

Reviewers: rjmccall

Subscribers: jdoerfert, cfe-commits

Tags: #clang

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

llvm-svn: 363428
2019-06-14 17:46:37 +00:00
Nico Weber 3d02b895ed Revert 363295, it caused PR42276. Also revert follow-ups 363337, 363340.
Revert 363340 "Remove unused SK_LValueToRValue initialization step."
Revert 363337 "PR23833, DR2140: an lvalue-to-rvalue conversion on a glvalue of type"
Revert 363295 "C++ DR712 and others: handle non-odr-use resulting from an lvalue-to-rvalue conversion applied to a member access or similar not-quite-trivial lvalue expression."

llvm-svn: 363352
2019-06-14 04:05:17 +00:00
Richard Smith 17965d42f4 C++ DR712 and others: handle non-odr-use resulting from an lvalue-to-rvalue conversion applied to a member access or similar not-quite-trivial lvalue expression.
Summary:
When a variable is named in a context where we can't directly emit a
reference to it (because we don't know for sure that it's going to be
defined, or it's from an enclosing function and not captured, or the
reference might not "work" for some reason), we emit a copy of the
variable as a global and use that for the known-to-be-read-only access.

Reviewers: rjmccall

Subscribers: jdoerfert, cfe-commits

Tags: #clang

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

llvm-svn: 363295
2019-06-13 19:00:16 +00:00
Richard Smith b23c5e8c3d [c++20] Implement P0846R0: allow (ADL-only) calls to template-ids whose
template name is not visible to unqualified lookup.

In order to support this without a severe degradation in our ability to
diagnose typos in template names, this change significantly restructures
the way we handle template-id-shaped syntax for which lookup of the
template name finds nothing.

Instead of eagerly diagnosing an undeclared template name, we now form a
placeholder template-name representing a name that is known to not find
any templates. When the parser sees such a name, it attempts to
disambiguate whether we have a less-than comparison or a template-id.
Any diagnostics or typo-correction for the name are delayed until its
point of use.

The upshot should be a small improvement of our diagostic quality
overall: we now take more syntactic context into account when trying to
resolve an undeclared identifier on the left hand side of a '<'. In
fact, this works well enough that the backwards-compatible portion (for
an undeclared identifier rather than a lookup that finds functions but
no function templates) is enabled in all language modes.

llvm-svn: 360308
2019-05-09 03:31:27 +00:00
Bruno Ricci af3e50ad40 [Sema] ADL: Associated namespaces for class types and enumeration types (CWG 1691)
CWG 1691 changed the definition of the namespaces associated with a class
type or enumeration type.

For a class type, the associated namespaces are the innermost enclosing
namespaces of the associated classes. For an enumeration type, the associated
namespace is the innermost enclosing namespace of its declaration.

This also fixes CWG 1690 and CWG 1692.

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

Reviewed By: rjmccall, rsmith

llvm-svn: 358882
2019-04-22 12:19:00 +00:00
Bruno Ricci 1f30dba14d [Sema][NFC] Add more tests for the behavior of argument-dependent name lookup
The goal here is to exercise each rule in [basic.lookup.argdep] at least once.
These new tests expose what I believe are 2 issues:

1. CWG 1691 needs to be implemented (p2:  [...] Its associated namespaces are
   the innermost enclosing namespaces of its associated classes [...]) The
   corresponding tests are adl_class_type::X2 and adl_class_type::X5.

2. The end of paragraph 2 ([...] Additionally, if the aforementioned set of
   overloaded functions is named with a template-id, its associated classes
   and namespaces also include those of its type template-arguments and its
   template template-arguments.) is not implemented. Closely related, the
   restriction on non-dependent parameter types in this same paragraph needs
   to be removed. The corresponding tests are in adl_overload_set (both issues
   are from CWG 997).

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

Reviewed By: riccibruno, Quuxplusone

llvm-svn: 358881
2019-04-22 11:40:31 +00:00
Richard Smith a5bbbfef15 [c++2a] Add semantic support for private module fragments.
llvm-svn: 358713
2019-04-18 21:12:54 +00:00
Richard Smith e867e98314 [c++2a] Improve diagnostic for use of declaration from another TU's
global module fragment.

We know that the declaration in question should have been introduced by
a '#include', so try to figure out which one and suggest it. Don't
suggest importing the global module fragment itself!

llvm-svn: 358631
2019-04-18 00:56:58 +00:00
Richard Smith d652bdd05f [c++20] Parsing support for module-declarations, import-declarations,
and the global and private module fragment.

For now, the private module fragment introducer is ignored, but use of
the global module fragment introducer should be properly enforced.

llvm-svn: 358353
2019-04-14 08:06:59 +00:00
Richard Smith 69bc9aa22f Restore pre-r335182 behavior for naming inherited constructors as
members of dependent contexts.

This permits cases where the names before and after the '::' in a
dependent inherited constructor using-declaration do not match, but
where we can nonetheless tell when parsing the template that a
constructor is being named. Under (open) core language DR 2070, such
cases will probably be ill-formed, but r335182 does not quite give
that result and didn't intend to change this, so restore the old
behavior for now.

llvm-svn: 335381
2018-06-22 19:50:19 +00:00
Richard Smith ac63d63543 Add a "vexing parse" warning for ambiguity between a variable declaration and a
function-style cast.

This fires for cases such as

  T(x);

... where 'x' was previously declared and T is a type. This construct declares
a variable named 'x' rather than the (probably expected) interpretation of a
function-style cast of 'x' to T.

llvm-svn: 314570
2017-09-29 23:57:25 +00:00
Richard Smith cdb06f2150 Correctly compute linkage for members of internal linkage classes.
We used to give such members no linkage instead of giving them the linkage of
the class.

llvm-svn: 314054
2017-09-23 04:02:17 +00:00
Richard Smith df963a38a9 DR1113: anonymous namespaces formally give their contents internal linkage.
This doesn't affect our code generation in any material way -- we already give
such declarations internal linkage from a codegen perspective -- but it has
some subtle effects on code validity.

We suppress the 'L' (internal linkage) marker for mangled names in anonymous
namespaces, because it is redundant (the information is already carried by the
namespace); this deviates from GCC's behavior if a variable or function in an
anonymous namespace is redundantly declared 'static' (where GCC does include
the 'L'), but GCC's behavior is incoherent because such a declaration can be
validly declared with or without the 'static'.

We still deviate from the standard in one regard here: extern "C" declarations
in anonymous namespaces are still granted external linkage. Changing those does
not appear to have been an intentional consequence of the standard change in
DR1113.

llvm-svn: 314037
2017-09-22 22:21:44 +00:00
Richard Smith 7ff8304db7 Closure types have no name (and can't have a typedef name for linkage
purposes), so they never formally have linkage.

llvm-svn: 313957
2017-09-22 04:33:20 +00:00
Richard Smith 405e2dbf37 Implement C++ [basic.link]p8.
If a function or variable has a type with no linkage (and is not extern "C"),
any use of it requires a definition within the same translation unit; the idea
is that it is not possible to define the entity elsewhere, so any such use is
necessarily an error.

There is an exception, though: some types formally have no linkage but
nonetheless can be referenced from other translation units (for example, this
happens to anonymous structures defined within inline functions). For entities
with those types, we suppress the diagnostic except under -pedantic.

llvm-svn: 313729
2017-09-20 07:22:00 +00:00
Richard Smith b8c419085f Add IDNS_Tag to C++ declarations that conflict with tag declarations.
Fixes some accepts-invalids with tags and other declarations declared in the
same scope.

llvm-svn: 312743
2017-09-07 20:22:00 +00:00
Alex Lorenz 76377dcf99 Print nested name specifiers for typedefs and type aliases
Printing typedefs or type aliases using clang_getTypeSpelling() is missing the
namespace they are defined in. This is in contrast to other types that always
yield the full typename including namespaces.

Patch by Michael Reiher!

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

llvm-svn: 297465
2017-03-10 15:04:58 +00:00
Richard Smith 62559bd7ce Fix hole in our enforcement of rule requiring 'typename' prior to a dependent
name. If the dependent name happened to end in a template-id (X<T>::Y<U>), we
would fail to notice that the 'typename' keyword is missing when resolving it
to a type.

It turns out that GCC has a similar bug. If this shows up in much real code, we
can easily downgrade this to an ExtWarn.

llvm-svn: 293815
2017-02-01 21:36:38 +00:00
Richard Smith fd3dae024f Finish implementation of C++ DR1310 (http://wg21.link/cwg1310).
Diagnose the case when a dependent template name instantiates to an
injected-class-name outside a nested-name-specifier.

llvm-svn: 292545
2017-01-20 00:20:39 +00:00
Richard Smith 74f02347ca PR13403 (+duplicates): implement C++ DR1310 (http://wg21.link/cwg1310).
Under this defect resolution, the injected-class-name of a class or class
template cannot be used except in very limited circumstances (when declaring a
constructor, in a nested-name-specifier, in a base-specifier, or in an
elaborated-type-specifier). This is apparently done to make parsing easier, but
it's a pain for us since we don't know whether a template-id using the
injected-class-name is valid at the point when we annotate it (we don't yet
know whether the template-id will become part of an elaborated-type-specifier).

As a tentative resolution to a perceived language defect, mem-initializer-ids
are added to the list of exceptions here (they generally follow the same rules
as base-specifiers).

When the reference to the injected-class-name uses the 'typename' or 'template'
keywords, we permit it to be used to name a type or template as an extension;
other compilers also accept some cases in this area. There are also a couple of
corner cases with dependent template names that we do not yet diagnose, but
which will also get this treatment.

llvm-svn: 292518
2017-01-19 21:00:13 +00:00
David L. Jones f55ce36c02 Allow constexpr construction of subobjects unconditionally, not just in C++14.
Summary:
Per https://wg21.link/CWG1677, the C++11 standard did not clarify that constant
initialization of an object allowed constexpr brace-or-equal initialization of
subobjects:

  struct foo_t { union { int i; volatile int j; } u; };

  __attribute__((__require_constant_initialization__))
  static const foo_t x = {{0}};

Because foo_t::u has a volatile member, the initializer for x fails. However,
there is really no good reason, because this:

  union foo_u { int i; volatile int j; };
  __attribute__((__require_constant_initialization__))
  static const foo_u x = {0};

does have a constant initializer.

(This was triggered by musl's pthread_mutex_t type when building under C++11.)

Reviewers: rsmith

Subscribers: EricWF, cfe-commits

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

llvm-svn: 291480
2017-01-09 21:38:07 +00:00
Reid Kleckner 1a4ab7e772 Improve error message when referencing a non-tag type with a tag
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
2016-12-09 19:47:58 +00:00
Richard Smith b2f0f05742 Re-commit r283722, reverted in r283750, with a fix for a CUDA-specific use of
past-the-end iterator.

Original commit message:

P0035R4: Semantic analysis and code generation for C++17 overaligned
allocation.

llvm-svn: 283789
2016-10-10 18:54:32 +00:00
Daniel Jasper e9abe64816 Revert "P0035R4: Semantic analysis and code generation for C++17 overaligned allocation."
This reverts commit r283722. Breaks:
  Clang.SemaCUDA.device-var-init.cu
  Clang.CodeGenCUDA.device-var-init.cu

http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-expensive/884/

llvm-svn: 283750
2016-10-10 14:13:55 +00:00
Richard Smith 189e52fcdf P0035R4: Semantic analysis and code generation for C++17 overaligned
allocation.

llvm-svn: 283722
2016-10-10 06:42:31 +00:00
Richard Smith e3ea001ec8 Don't diagnoes a mismatch between implicit and explicit exception
specifications under -fno-exceptions, just as we don't diagnose other exception
specification mismatch errors.

llvm-svn: 280289
2016-08-31 20:38:32 +00:00
Richard Smith 5179eb7821 P0136R1, DR1573, DR1645, DR1715, DR1736, DR1903, DR1941, DR1959, DR1991:
Replace inheriting constructors implementation with new approach, voted into
C++ last year as a DR against C++11.

Instead of synthesizing a set of derived class constructors for each inherited
base class constructor, we make the constructors of the base class visible to
constructor lookup in the derived class, using the normal rules for
using-declarations.

For constructors, UsingShadowDecl now has a ConstructorUsingShadowDecl derived
class that tracks the requisite additional information. We create shadow
constructors (not found by name lookup) in the derived class to model the
actual initialization, and have a new expression node,
CXXInheritedCtorInitExpr, to model the initialization of a base class from such
a constructor. (This initialization is special because it performs real perfect
forwarding of arguments.)

In cases where argument forwarding is not possible (for inalloca calls,
variadic calls, and calls with callee parameter cleanup), the shadow inheriting
constructor is not emitted and instead we directly emit the initialization code
into the caller of the inherited constructor.

Note that this new model is not perfectly compatible with the old model in some
corner cases. In particular:
 * if B inherits a private constructor from A, and C uses that constructor to
   construct a B, then we previously required that A befriends B and B
   befriends C, but the new rules require A to befriend C directly, and
 * if a derived class has its own constructors (and so its implicit default
   constructor is suppressed), it may still inherit a default constructor from
   a base class

llvm-svn: 274049
2016-06-28 19:03:57 +00:00
Richard Smith 62f19e700d Implement C++17 P0386R2, inline variables. (The 'inline' specifier gives a
variable weak discardable linkage and partially-ordered initialization, and is
implied for constexpr static data members.)

llvm-svn: 273754
2016-06-25 00:15:56 +00:00
Charles Li 1a88adbb27 Lit C++11 Compatibility Patch #8
24 tests have been updated for C++11 compatibility.

llvm-svn: 266387
2016-04-14 23:47:07 +00:00
Charles Li e7cbb3ed4f [Lit Test] Updated 34 Lit tests to be C++11 compatible.
Added expected diagnostics new to C++11.
Expanded RUN line to: default, C++98/03 and C++11.

llvm-svn: 253371
2015-11-17 20:25:05 +00:00
Davide Italiano da8a3b903b [Sema] main can't be declared as global variable, in C++.
So, we now reject that. We also warn for any external-linkage global
variable named main in C, because it results in undefined behavior.

PR:	  24309
Differential Revision:	http://reviews.llvm.org/D11658
Reviewed by:	rsmith

llvm-svn: 245051
2015-08-14 14:13:29 +00:00
David Majnemer bc4cc14cd7 [Sema] Don't crash if array bound calculation overflowed constexpr array
We didn't correctly expect a QualifiedTypeLoc when faced with fixing a
variable array type into a constant array type.

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

llvm-svn: 235251
2015-04-18 04:55:51 +00:00
Serge Pavlov f80df57d39 Update error message text.
Previously if an enumeration was used in a nested name specifier in pre-C++11
language dialect, error message was 'XXX is not a class, namespace, or scoped
enumeration'. This patch removes the word 'scoped' as in C++11 any enumeration
may be used in this context.

llvm-svn: 226410
2015-01-18 19:05:48 +00:00
Richard Smith d52186ff5a DR1684: a constexpr member function need not be a member of a literal class type.
llvm-svn: 224388
2014-12-16 23:12:52 +00:00
Alp Toker a3c494f0db Revert "clang/test/Driver/crash-report.c: This requires rewriter for -frewrite-includes. [PR20321]"
We've decided to make the core rewriter class and PP rewriters mandatory.
They're only a few hundred lines of code in total and not worth supporting as a
distinct build configuration, especially since doing so disables key compiler
features.

This reverts commit r213150.

Revert "clang/test: Introduce the feature "rewriter" for --enable-clang-rewriter."

This reverts commit r213148.

Revert "Move clang/test/Frontend/rewrite-*.c to clang/test/Frontend/Rewriter/"

This reverts commit r213146.

llvm-svn: 213159
2014-07-16 15:12:48 +00:00
NAKAMURA Takumi 692d6bb544 clang/test: Introduce the feature "rewriter" for --enable-clang-rewriter.
llvm-svn: 213148
2014-07-16 13:36:39 +00:00
Alp Toker 70fc29ca86 Don't accept qualified 'int' main return types in C++ or standard C mode
C++ [basic.start.main]p1: "It shall have a return type of type int"

ISO C is also clear about this, so only accept 'int' with qualifiers in GNUMode
C.

llvm-svn: 212171
2014-07-02 07:07:20 +00:00
Aaron Ballman 9ef622e5bf The exception-declaration for a function-try-block cannot redeclare a
function parameter. One of our existing test cases was XFAILed because
of this. This fixes the issue and un-XFAILs the test.

llvm-svn: 210026
2014-06-02 13:10:07 +00:00
Aaron Ballman 3e44a7fa52 This test should no longer be XFAILed; the standard has stabilized, and the test contents are acceptable. No diagnostics expected from this test.
llvm-svn: 209891
2014-05-30 13:09:38 +00:00
Alp Toker 6cfe412e6e Test requires exceptions
It's still XFAIL, but slightly closer to passing.

llvm-svn: 209729
2014-05-28 12:20:23 +00:00
David Majnemer e37a6ce9f7 Sema: Implement DR244
Summary:
Naming the destructor using a typedef-name for the class-name is
well-formed.

This fixes PR19620.

Reviewers: rsmith, doug.gregor

Subscribers: cfe-commits

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

llvm-svn: 209319
2014-05-21 20:19:59 +00:00
David Majnemer a2245271af Revert "Sema: Implement DR244"
This was accidentally committed.

This reverts commit r207892.

llvm-svn: 207893
2014-05-03 02:22:11 +00:00
David Majnemer 22fcb08357 Sema: Implement DR244
Naming the destructor using a typedef-name for the class-name is
well-formed.

This fixes PR19620.

llvm-svn: 207892
2014-05-03 02:18:46 +00:00
Richard Smith baf3ca5c01 Don't fold together the name lookup entries for two declarations if they are
declared in different namespaces in the same inline namespace set.

llvm-svn: 204082
2014-03-17 21:46:03 +00:00
David Blaikie 6cab596218 Improve diagnostic for using non-class/namespace/scoped enum in a nested name specifier.
Rather than simply saying "X is not a class or namespace", clarify what
X is by providing the aka type in the case where X is a type, or
pointing to the named declaration if there's an unambiguous one to refer
to. In the ambiguous case, the ambiguities are already enumerated
(though could be clarified by describing what kind of entities they are)

Included a few FIXMEs in tests where some further improvements could be
made.

llvm-svn: 201038
2014-02-09 06:54:23 +00:00