| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
to the ambiguity, rather than noting all viable candidates.
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D63894
llvm-svn: 365555
|
|
|
|
|
|
| |
constructors to better match the pre-P0136R1 behavior.
llvm-svn: 291955
|
|
|
|
|
|
|
|
|
|
|
|
| |
constructor.
The rule we use is that a construction of a class type T from an argument of
type U cannot use an inherited constructor if U is the same as T or is derived
from T (or if the initialization would first convert it to such a type). This
(approximately) matches the rule in use by GCC, and matches the current proposed
DR resolution.
llvm-svn: 291403
|
|
|
|
|
|
| |
using-declarations.
llvm-svn: 290072
|
|
|
|
|
|
|
|
|
|
|
| |
* a dependent non-type using-declaration within a function template can be
valid, as it can refer to an enumerator, so don't reject it in the template
definition
* we can partially substitute into a dependent using-declaration if it appears
within a (local class in a) generic lambda within a function template, which
means an UnresolvedUsing*Decl doesn't necessarily instantiate to a UsingDecl.
llvm-svn: 290071
|
|
|
|
|
|
|
| |
just warn that the second declaration is missing the 'inline' keyword. This is
valid, and we shouldn't be suggesting otherwise.
llvm-svn: 282981
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
a base class via a using-declaration. If a class has a using-declaration
declaring either a constructor or an assignment operator, eagerly declare its
special members in case they need to displace a shadow declaration from a
using-declaration.
llvm-svn: 269398
|
|
|
|
| |
llvm-svn: 268665
|
|
|
|
|
|
| |
using-declaration that names a class-scope enumerator.
llvm-svn: 268664
|
|
|
|
|
|
|
|
|
|
|
| |
enumerators:
* an unscoped enumerator whose enumeration is a class member is itself a class
member, so can only be the subject of a class-scope using-declaration.
* a scoped enumerator cannot be the subject of a class-scope using-declaration.
llvm-svn: 268594
|
|
|
|
|
|
|
| |
Added expected diagnostics new to C++11.
Expanded RUN line to: default, C++98/03 and C++11.
llvm-svn: 253371
|
|
|
|
|
|
|
|
|
| |
This code was written with the intent that a pointer could be null but
we dyn_cast'd it anyway. Change the dyn_cast to a dyn_cast_or_null.
This fixes PR21933.
llvm-svn: 224411
|
|
|
|
|
|
| |
to suggest a different syntax to get the same effect.
llvm-svn: 205467
|
|
|
|
| |
llvm-svn: 203302
|
|
|
|
| |
llvm-svn: 202925
|
|
|
|
|
|
|
|
| |
using-declaration, and they declare the same function (either because
the using-declaration is in the same namespace as the declaration it
imports, or because they're both extern "C"), they do not conflict.
llvm-svn: 200897
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The removal is tried by retrying the failed lookup of a correction
candidate with either the MemberContext or SS (CXXScopeSpecifier) or
both set to NULL if they weren't already. If the candidate identifier
is then looked up successfully, make a note in the candidate that the
SourceRange should include any existing nested name specifier even if
the candidate isn't adding a different one (i.e. the candidate has a
NULL NestedNameSpecifier).
Also tweak the diagnostic messages to differentiate between a suggestion
that just replaces the identifer but leaves the existing nested name
specifier intact and one that replaces the entire qualified identifier,
in cases where the suggested replacement is unqualified.
llvm-svn: 185487
|
|
|
|
|
|
| |
namespaces to try for potential typo corrections.
llvm-svn: 184762
|
|
|
|
|
|
|
|
| |
performing unqualified lookup for a friend class declaration.
rdar://13393749
llvm-svn: 177473
|
|
|
|
|
|
| |
unresolved using declarations. Fixes PR14768 / <rdar://problem/13030296>.
llvm-svn: 173883
|
|
|
|
|
|
| |
VerifyDiagnosticConsumer, make the necessary adjustment to 580 test-cases which will henceforth require this new directive.
llvm-svn: 166280
|
|
|
|
|
|
|
|
| |
a non-inline namespace, then reopens it as inline to try to add its symbols to
the surrounding namespace. In this one special case, permit the namespace to be
reopened as inline, and patch up the name lookup tables to match.
llvm-svn: 165263
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- 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
|
|
|
|
|
|
|
|
| |
int f();
in function scopes under -Wvexing-parse, so now we do.
llvm-svn: 147649
|
|
|
|
|
|
|
| |
the Semantic Powers to only warn on class types (or dependent types), where the
constructor or destructor could do something interesting.
llvm-svn: 147642
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
-std=c++0x. Patch by Ahmed Charles!
llvm-svn: 141900
|
|
|
|
|
|
|
| |
to a warning, since apparently libstdc++'s debug mode does this (and
we can recover safely). Add a Fix-It to insert the "inline", just for kicks.
llvm-svn: 131732
|
|
|
|
|
|
|
|
|
|
|
| |
of a C++0x inline namespace within enclosing namespaces, as noted in
C++0x [namespace.def]p8.
Fixes <rdar://problem/9006349>, a libc++ failure where Clang was
rejected an explicit specialization of std::swap (since libc++ puts it
into an inline, versioned namespace std::__1).
llvm-svn: 127162
|
|
|
|
|
|
| |
from Alex Miller!
llvm-svn: 124663
|
|
|
|
| |
llvm-svn: 120296
|
|
|
|
|
|
|
|
| |
Not sure what I was thinking before.
Fixes PR8668.
llvm-svn: 120063
|
|
|
|
|
|
|
| |
the current context's redeclaration context, ignoring using
directives. Fixes PR8430.
llvm-svn: 117097
|
|
|
|
| |
llvm-svn: 116529
|
|
|
|
|
|
| |
doesn't fit. Instead, special-case the few places where transparent contexts have the desired behavior for inline namespaces. Fixes a redeclaration issue in inline namespaces.
llvm-svn: 112637
|
|
|
|
| |
llvm-svn: 112566
|
|
|
|
|
|
| |
testcase for inline namespace fun.
llvm-svn: 112565
|
|
|
|
| |
llvm-svn: 112564
|
|
|
|
| |
llvm-svn: 112320
|
|
|
|
|
|
|
|
| |
that actually refer to the same underlying type, it is not an
ambiguity; add uniquing support based on the canonical type of type
declarations. Fixes <rdar://problem/8296180>.
llvm-svn: 110806
|
|
|
|
|
|
|
|
| |
typedefs won't have the same canonical declaration (since they are
distinct), so we need to check for this case specifically. Fixes
<rdar://problem/8018262>.
llvm-svn: 107833
|
|
|
|
| |
llvm-svn: 107153
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
introduced by using decls are hidden even if their template parameter lists
or return types differ from the "overriding" declaration.
Propagate using shadow declarations around more effectively when looking up
template-ids. Reperform lookup for template-ids in member expressions so that
access control is properly set up.
Fix some number of latent bugs involving template-ids with totally invalid
base types. You can only actually get these with a scope specifier, since
otherwise the template-id won't parse as a template-id.
Fixes PR7384.
llvm-svn: 106093
|
|
|
|
|
|
| |
scope. Thanks to Steven Watanabe for correcting me.
llvm-svn: 103210
|
|
|
|
| |
llvm-svn: 102163
|
|
|
|
|
|
| |
elaborated-type-specifiers. Patch by Enea Zaffanella!
llvm-svn: 102065
|