| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
my defaulted constructor tests stop yelling at me about them.
llvm-svn: 131432
|
| |
|
|
|
|
|
|
|
|
|
|
| |
template<class U>
struct X1 {
template<class T> void f(T*);
template<> void f(int*) { }
};
Won't be so simple. I need to think more about it.
llvm-svn: 131362
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
scope.
Necessary to parse MFC and MSVC standard lib code.
Example:
struct X {
template<class T> void f(T) { }
template<> void f(int) { }
}
llvm-svn: 131347
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
They are actually grammatically considered definitions and parsed
accordingly.
This fixes the outstanding bugs regarding defaulting functions after
their declarations.
We now really nicely diagnose the following construct (try it!)
int foo() = delete, bar;
Still todo: Defaulted functions other than default constructors
Test cases (including for the above construct)
llvm-svn: 131228
|
| |
|
|
|
|
|
| |
We still don't parse out-of-line defaults correctly, which is needed to
get the full effect out of this patch.
llvm-svn: 131223
|
| |
|
|
| |
llvm-svn: 131212
|
| |
|
|
|
|
| |
This means we get C++0x jump-across-intializer semantics correct.
llvm-svn: 131204
|
| |
|
|
|
|
|
|
| |
Yes, I'm aware that the diagnostics are awful.
Tests to follow.
llvm-svn: 131203
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
class scope.
This removes 2 errors when parsing MFC code with clang
Example:
class A {
virtual void f() = 0 { }
}
llvm-svn: 131175
|
| |
|
|
|
|
|
|
|
| |
I've edited one diagnostic which would print "copy constructor" for copy
constructors and "constructor" for any other constructor. If anyone is
extremely enamored with this, it can be reinstated with a simple boolean
flag rather than calling getSpecialMember, which is inappropriate.
llvm-svn: 131143
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the semantic context referenced by the nested-name-specifier rather
than the syntactic form of the nested-name-specifier. The previous
incarnation was based on my complete misunderstanding of C++
[temp.expl.spec]. The latest C++0x working draft clarifies the
requirements here, and this rewrite is intended to follow that.
Along the way, improve source location information in the
diagnostics. For example, if we report that a specific type needs or
doesn't need a 'template<>' header, we dig out that type in the
nested-name-specifier and highlight its range.
Fixes: PR5907, PR9421, PR8277, PR8708, PR9482, PR9668, PR9877, and
<rdar://problem/9135379>.
llvm-svn: 131138
|
| |
|
|
| |
llvm-svn: 131126
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Focus is on default constructors for the time being. Currently the
exception specification and prototype are processed correctly. Codegen
might work but in all likelihood doesn't.
Note that due to an error, out-of-line defaulting of member functions is
currently impossible. It will continue to that until I muster up the
courage to admit that I secretly pray to epimetheus and that I need to
rework the way default gets from Parse -> Sema.
llvm-svn: 131115
|
| |
|
|
|
|
| |
reflect our new, more accurate AST.
llvm-svn: 131114
|
| |
|
|
|
|
| |
unions. Fixes PR8326.
llvm-svn: 131109
|
| |
|
|
|
|
| |
definitions to also include tag declarations. Fixes PR8151.
llvm-svn: 131102
|
| |
|
|
|
|
|
| |
modify the semantics slightly to accomodate default constructors (I
hope).
llvm-svn: 131087
|
| |
|
|
| |
llvm-svn: 131018
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- New isDefined() function checks for deletedness
- isThisDeclarationADefinition checks for deletedness
- New doesThisDeclarationHaveABody() does what
isThisDeclarationADefinition() used to do
- The IsDeleted bit is not propagated across redeclarations
- isDeleted() now checks the canoncial declaration
- New isDeletedAsWritten() does what it says on the tin.
- isUserProvided() now correct (thanks Richard!)
This fixes the bug that we weren't catching
void foo() = delete;
void foo() {}
as being a redefinition.
llvm-svn: 131013
|
| |
|
|
|
|
|
|
| |
Explictly defaultedness is correctly reflected on the AST, but there are
no changes to how that affects the definition of functions or much else
really.
llvm-svn: 130974
|
| |
|
|
|
|
|
| |
direction and not introduce things in the wrong place three different
times.
llvm-svn: 130968
|
| |
|
|
| |
llvm-svn: 130953
|
| |
|
|
|
|
| |
There's some unused stuff for now.
llvm-svn: 130912
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
tag, filter out those ambiguous names that we found if they aren't
within the declaration context where this newly-defined tag will be
visible.
This is basically a hack, because we really need to fix the lookup of
tag declarations in this case to not find things it
shouldn't. However, it's better than what we had before, and it fixes
<rdar://problem/9168556>.
llvm-svn: 130810
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
parameters on the floor in certain cases:
class X {
template <typename T> friend typename A<T>::Foo;
};
This was parsed as a *non* template friend declaration some how, and
received an ExtWarn. Fixing the parser to actually provide the template
parameters to the freestanding declaration parse triggers the code which
specifically looks for such constructs and hard errors on them.
Along the way, this prevents us from trying to instantiate constructs
like the above inside of a outer template. This is important as loosing
the template parameters means we don't have a well formed declaration
and template instantiation will be unable to rebuild the AST. That fixes
a crash in the GCC test suite.
llvm-svn: 130772
|
| |
|
|
|
|
|
|
|
|
| |
parameter node and use this to correctly mangle parameter
references in function template signatures.
A follow-up patch will improve the storage usage of these
fields; here I've just done the lazy thing.
llvm-svn: 130669
|
| |
|
|
|
|
|
|
|
| |
in the classification of template names and using declarations. We now
properly typo-correct the leading identifiers in statements to types,
templates, values, etc. As an added bonus, this reduces the number of
lookups required for disambiguation.
llvm-svn: 130288
|
| |
|
|
|
|
|
|
| |
looking at the context and the correction and using a custom
diagnostic. Also, enable some Fix-It tests that were somewhat lamely
disabled.
llvm-svn: 130283
|
| |
|
|
|
|
| |
(and ignore it for now) - wip.
llvm-svn: 130224
|
| |
|
|
|
|
| |
rdar://8883302, this time for C++ as well.
llvm-svn: 130157
|
| |
|
|
|
|
|
| |
invalid expression rather than the far-more-generic "error". Fixes a
mild regression in error recovery uncovered by the GCC testsuite.
llvm-svn: 130128
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
performs name lookup for an identifier and resolves it to a
type/expression/template/etc. in the same step. This scheme is
intended to improve both performance (by reducing the number of
redundant name lookups for a given identifier token) and error
recovery (by giving Sema a chance to correct type names before the
parser has decided that the identifier isn't a type name). For
example, this allows us to properly typo-correct type names at the
beginning of a statement:
t.c:6:3: error: use of undeclared identifier 'integer'; did you mean
'Integer'?
integer *i = 0;
^~~~~~~
Integer
t.c:1:13: note: 'Integer' declared here
typedef int Integer;
^
Previously, we wouldn't give a Fix-It because the typo correction
occurred after the parser had checked whether "integer" was a type
name (via Sema::getTypeName(), which isn't allowed to typo-correct)
and therefore decided to parse "integer * i = 0" as an expression. By
typo-correcting earlier, we typo-correct to the type name Integer and
parse this as a declaration.
Moreover, in this context, we can also typo-correct identifiers to
keywords, e.g.,
t.c:7:3: error: use of undeclared identifier 'vid'; did you mean
'void'?
vid *p = i;
^~~
void
and recover appropriately.
Note that this is very much a work-in-progress. The new
Sema::ClassifyName is only used for expression-or-declaration
disambiguation in C at the statement level. The next steps will be to
make this work for the same disambiguation in C++ (where
functional-style casts make some trouble), then push it
further into the parser to eliminate more redundant name lookups.
Fixes <rdar://problem/7963833> for C and starts us down the path of
<rdar://problem/8172000>.
llvm-svn: 130082
|
| |
|
|
|
|
| |
-flate-template-parsing mode.
llvm-svn: 130030
|
| |
|
|
|
|
|
|
|
| |
function definitions are parsed at the end of the translation unit only if it is required by an actual instantiation. As such all the symbols of the TU are available during name lookup.
Using this flag is necessary for compatibility with Microsoft template code.
This also provides some parsing speed improvement.
llvm-svn: 130022
|
| |
|
|
|
|
| |
warning in Microsoft mode.
llvm-svn: 130010
|
| |
|
|
|
|
|
|
|
| |
cases that demonstrates exactly why this does indeed apply in 0x mode.
If isPOD is currently broken in 0x mode, we should fix that directly
rather than papering over it here.
llvm-svn: 130007
|
| |
|
|
|
|
| |
warnings I introduced lately.
llvm-svn: 129986
|
| |
|
|
|
|
| |
to a warning in Microsoft mode.
llvm-svn: 129985
|
| |
|
|
| |
llvm-svn: 129823
|
| |
|
|
| |
llvm-svn: 129567
|
| |
|
|
|
|
| |
draft standard (N3291).
llvm-svn: 129541
|
| |
|
|
| |
llvm-svn: 129426
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the type of one of the base classes then downgrade the missing typename error to a warning. Up to now this is the only case I found where MSVC doesn't require "typename" at class scope. Really strange!
This fixes 1 error when parsing the MSVC 2008 header files.
Example:
template<class T> class A {
public:
typedef int TYPE;
};
template<class T> class B : public A<T> {
public:
A<T>::TYPE a; // no typename required because A<T> is a base class.
};
llvm-svn: 129425
|
| |
|
|
|
|
| |
pageexec@freemail.hu, tweaks by me.
llvm-svn: 129206
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch authored by Eric Niebler.
Many methods on the Sema class (e.g. ConvertPropertyForRValue) take Expr
pointers as in/out parameters (Expr *&). This is especially true for the
routines that apply implicit conversions to nodes in-place. This design is
workable only as long as those conversions cannot fail. If they are allowed
to fail, they need a way to report their failures. The typical way of doing
this in clang is to use an ExprResult, which has an extra bit to signal a
valid/invalid state. Returning ExprResult is de riguour elsewhere in the Sema
interface. We suggest changing the Expr *& parameters in the Sema interface
to ExprResult &. This increases interface consistency and maintainability.
This interface change is important for work supporting MS-style C++
properties. For reasons explained here
<http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-February/013180.html>,
seemingly trivial operations like rvalue/lvalue conversions that formerly
could not fail now can. (The reason is that given the semantics of the
feature, getter/setter method lookup cannot happen until the point of use, at
which point it may be found that the method does not exist, or it may have the
wrong type, or overload resolution may fail, or it may be inaccessible.)
llvm-svn: 129143
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
numerous CFG and UninitializedValues analysis changes:
1) Change the CFG to include the DeclStmt for conditional variables, instead of using the condition itself as a faux DeclStmt.
2) Update ExprEngine (the static analyzer) to understand (1), so not to regress.
3) Update UninitializedValues.cpp to initialize all tracked variables to Uninitialized at the start of the function/method.
4) Only use the SelfReferenceChecker (SemaDecl.cpp) on global variables, leaving the dataflow analysis to handle other cases.
The combination of (1) and (3) allows the dataflow-based -Wuninitialized to find self-init problems when the initializer
contained control-flow.
llvm-svn: 128858
|
| |
|
|
|
|
|
|
| |
Microsoft mode.
This fixes a bunch of errors when compiling MSVC header files with the -DDLL flag.
llvm-svn: 128457
|
| |
|
|
|
|
|
|
|
|
|
| |
This is basically the same idea as the warning on uninitialized uses of
fields within an initializer list. As such, it is on by default and
under -Wuninitialized.
Original patch by Richard Trieu, with some massaging from me on the
wording and grouping of the diagnostics.
llvm-svn: 128376
|
| |
|
|
|
|
| |
usually useless, but not always.
llvm-svn: 128326
|
| |
|
|
|
|
| |
parse it though, although that will change shortly.
llvm-svn: 128277
|