| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
variable declarations where applicable. Also, a few fixes to
TryToFixInvalidVariablyModifiedType for issues that this exposed.
llvm-svn: 65500
|
| |
|
|
| |
llvm-svn: 65489
|
| |
|
|
|
|
|
|
| |
derive from a class template specialization, e.g.,
class B : public A<int> { };
llvm-svn: 65488
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
vector<vector<double>> Matrix;
In C++98/03, this token always means "right shift". However, if we're in
a context where we know that it can't mean "right shift", provide a
friendly reminder to put a space between the two >'s and then treat it
as two >'s as part of recovery.
In C++0x, this token is always broken into two '>' tokens.
llvm-svn: 65484
|
| |
|
|
|
|
|
|
|
|
|
| |
expressions of the form: 'short x = (y != 10);' While we handle 'int x = (y !=
10)' lazily, the cast to another integer type currently loses the symbolic
constraint. Eager evaluation of the constraint causes the paths to bifurcate and
eagerly evaluate 'y != 10' to a constant of 1 or 0. This should address
<rdar://problem/6619921> until we have a better (more lazy approach) for
handling promotions/truncations of symbolic integer values.
llvm-svn: 65480
|
| |
|
|
|
|
|
|
| |
decls. Test and document the semantic location of class template
specialization definitions that occur within a scope enclosing the
scope of the class template.
llvm-svn: 65478
|
| |
|
|
|
|
|
|
|
|
|
|
| |
specializations. In particular:
- Make sure class template specializations have a "template<>"
header, and complain if they don't.
- Make sure class template specializations are declared/defined
within a valid context. (e.g., you can't declare a specialization
std::vector<MyType> in the global namespace).
llvm-svn: 65476
|
| |
|
|
|
|
|
| |
code) when calling noreturn functions; general expression emission
isn't ready to do the right thing in all cases.
llvm-svn: 65473
|
| |
|
|
|
|
| |
- PR3662.
llvm-svn: 65472
|
| |
|
|
| |
llvm-svn: 65471
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
std::vector<int>::allocator_type
When we parse a template-id that names a type, it will become either a
template-id annotation (which is a parsed representation of a
template-id that has not yet been through semantic analysis) or a
typename annotation (where semantic analysis has resolved the
template-id to an actual type), depending on the context. We only
produce a type in contexts where we know that we only need type
information, e.g., in a type specifier. Otherwise, we create a
template-id annotation that can later be "upgraded" by transforming it
into a typename annotation when the parser needs a type. This occurs,
for example, when we've parsed "std::vector<int>" above and then see
the '::' after it. However, it means that when writing something like
this:
template<> class Outer::Inner<int> { ... };
We have two tokens to represent Outer::Inner<int>: one token for the
nested name specifier Outer::, and one template-id annotation token
for Inner<int>, which will be passed to semantic analysis to define
the class template specialization.
Most of the churn in the template tests in this patch come from an
improvement in our error recovery from ill-formed template-ids.
llvm-svn: 65467
|
| |
|
|
|
|
| |
PR3656.
llvm-svn: 65461
|
| |
|
|
|
|
|
|
|
|
| |
only from a function definition (that does not have a prototype) are
only used to determine the compatible with other declarations of that
same function. In particular, when referencing the function we pretend
as if it does not have a prototype. Implement this behavior, which
fixes PR3626.
llvm-svn: 65460
|
| |
|
|
| |
llvm-svn: 65420
|
| |
|
|
| |
llvm-svn: 65401
|
| |
|
|
|
|
| |
to SemaInit.cpp, no functionality change.
llvm-svn: 65394
|
| |
|
|
|
|
|
| |
The big difference here is that (like string literal) @encode has
array type, not pointer type.
llvm-svn: 65391
|
| |
|
|
|
|
|
| |
lookup to skip over names without linkage. This finishes
<rdar://problem/6127293>.
llvm-svn: 65386
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
external declarations to also support external variable
declarations. Unified the code for these two cases into two new
subroutines.
Note that we fail to diagnose cases like the one Neil pointed
out, where a visible non-external declaration hides an external
declaration by the same name. That will require some reshuffling of
name lookup.
llvm-svn: 65385
|
| |
|
|
|
|
|
| |
variables.
- PR3657.
llvm-svn: 65381
|
| |
|
|
| |
llvm-svn: 65374
|
| |
|
|
|
|
|
|
|
|
| |
that declaration to global scope so that it can be found from other
scopes. This allows us to diagnose redeclaration errors for external
declarations across scopes. We also warn when name lookup finds such
an out-of-scope declaration. This is part of <rdar://problem/6127293>;
we'll also need to do the same thing for variables.
llvm-svn: 65373
|
| |
|
|
|
|
|
|
|
| |
analyzer for array subscript expressions involving bases that are vectors. This
solution is probably a hack: it gets the lvalue of the vector instead of an
rvalue like all other types. This should be reviewed (big FIXME in
GRExprEngine).
llvm-svn: 65366
|
| |
|
|
|
|
|
|
|
| |
on should only be evaluated once, and it is evaluated outside the cleanup scope.
Also, lift SyncEnter and SyncExit up in nervous anticipation of x86-64
zero cost EH.
llvm-svn: 65362
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- When we are declaring a function in local scope, we can merge with
a visible declaration from an outer scope if that declaration
refers to an entity with linkage. This behavior now works in C++
and properly ignores entities without linkage.
- Diagnose the use of "static" on a function declaration in local
scope.
- Diagnose the declaration of a static function after a non-static
declaration of the same function.
- Propagate the storage specifier to a function declaration from a
prior declaration (PR3425)
- Don't name-mangle "main"
llvm-svn: 65360
|
| |
|
|
|
|
|
|
| |
assertion when the ivars and method list was reset into the existing
interface. To fix this, mark decls as invalid when they are redefined,
and don't insert ivars/methods into invalid decls.
llvm-svn: 65340
|
| |
|
|
|
|
| |
- Generate error for protocol qualifiers on non-ObjC types.
llvm-svn: 65333
|
| |
|
|
|
|
| |
Remove support for "Class<P>". Will be making this an error.
llvm-svn: 65332
|
| |
|
|
| |
llvm-svn: 65305
|
| |
|
|
|
|
| |
objects (opt for false negatives).
llvm-svn: 65304
|
| |
|
|
| |
llvm-svn: 65303
|
| |
|
|
| |
llvm-svn: 65299
|
| |
|
|
|
|
|
|
|
|
| |
<rdar://problem/6497631> Message lookup is sometimes different than gcc's).
- Implement instance/class overloading in ObjCContainerDecl (removing a FIXME). This involved hacking NamedDecl::declarationReplaces(), which took awhile to figure out (didn't realize replace was the default).
- Changed Sema::ActOnInstanceMessage() to remove redundant warnings when dealing with protocols. For now, I've omitted the "protocol" term in the diagnostic. It simplifies the code flow and wan't always 100% accurate (e.g. "Foo<Prot>" looks in the class interface, not just the protocol).
- Changed several test cases to jive with the above changes.
llvm-svn: 65292
|
| |
|
|
| |
llvm-svn: 65285
|
| |
|
|
| |
llvm-svn: 65270
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
helper isConstantInitializer) to check whether an initializer is
constant. This passes tests, but it's possible that it'll cause
regressions with real-world code.
Future work:
1. The diagnostics obtained this way are lower quality at the moment;
some work both here and in Evaluate is needed for accurate diagnostics.
2. We probably need some extra code when we're in -pedantic mode so we
can strictly enforce the rules in C99 6.6p7.
3. Dead code cleanup (this should wait until after 2, because we might
want to re-use some of the code).
llvm-svn: 65265
|
| |
|
|
|
|
| |
partially done in r65258.)
llvm-svn: 65260
|
| |
|
|
|
|
|
|
|
| |
PR3254 and part of PR3433.
The isICE changes are necessary to keep the computed results
consistent with Evaluate.
llvm-svn: 65258
|
| |
|
|
|
|
| |
Fixes PR3641.
llvm-svn: 65256
|
| |
|
|
| |
llvm-svn: 65255
|
| |
|
|
|
|
|
|
|
|
| |
required to actually be an error for correctness. The attached testcase
now gives an error instead of mysteriously crashing.
Now, it's possible we actually want to support the given usage, but I
haven't looked at the relevant code closely.
llvm-svn: 65253
|
| |
|
|
| |
llvm-svn: 65252
|
| |
|
|
|
|
|
|
| |
Found while researching <rdar://problem/6497631> Message lookup is sometimes different than gcc's.
Will never be seen in user code. Needed to pass dejagnu testsuite.
llvm-svn: 65244
|
| |
|
|
| |
llvm-svn: 65241
|
| |
|
|
|
|
| |
variable (objc2 gc specific).
llvm-svn: 65240
|
| |
|
|
| |
llvm-svn: 65235
|
| |
|
|
|
|
|
| |
expr; hilarity ensued.
- PR3640.
llvm-svn: 65234
|
| |
|
|
|
|
|
|
| |
<rdar://problem/6561076> [clang on Xcode] warning: cannot find protocol definition for 'OzzyP').
Removing the "cannot find protocol" warning is trivial if necessary (but I don't think it's the right thing to do).
llvm-svn: 65232
|
| |
|
|
|
|
|
|
|
|
| |
Move two key ObjC typechecks from Sema::CheckPointerTypesForAssignment() to ASTContext::mergeTypes().
This allows us to take advantage of the recursion in ASTContext::mergeTypes(), removing some bogus warnings.
This test case I've added includes an example where we still warn (and GCC doesn't). Need to talk with folks and decide what to do. At this point, the major bogosities should be fixed.
llvm-svn: 65231
|
| |
|
|
|
|
|
|
|
| |
handle method names that contain 'new', 'copy', etc., but those words might be
the substring of larger words such as 'newsgroup' and 'photocopy' that do not
indicate the allocation of objects. This should address the issues discussed in
<rdar://problem/6552389>.
llvm-svn: 65224
|