| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
| |
UnresolvedLookupExpr and UnresolvedMemberExpr.
Also, improve the computation that checks whether the base of a member
expression (either unresolved or dependent-scoped) is implicit. The
previous check didn't cover all of the cases we use in our
representation, which threw off source-location information for these
expressions (which, in turn, caused some breakage in libclang's token
annotation).
llvm-svn: 126681
|
| |
|
|
|
|
|
|
| |
CXXDependentScopeMemberExpr, and clean up instantiation of
nested-name-specifiers with dependent template specialization types in
the process.
llvm-svn: 126663
|
| |
|
|
|
|
|
|
| |
dependent template names. There is still a lot of redundant code in
TreeTransform to cope with TemplateSpecializationTypes, which I'll
remove in stages.
llvm-svn: 126656
|
| |
|
|
|
|
|
|
|
|
| |
C++ exceptions, even when exceptions have been turned off using -fno-exceptions.
Make the -fobjc-exceptions flag do the same thing, but for Objective-C exceptions.
C++ and Objective-C exceptions can also be disabled using -fno-cxx-excptions and
-fno-objc-exceptions.
llvm-svn: 126630
|
| |
|
|
|
|
|
|
|
|
|
|
| |
nested-name-specifier, e.g.,
T::template apply<U>::
represent the dependent template name specialization as a
DependentTemplateSpecializationType, rather than a
TemplateSpecializationType with a dependent TemplateName.
llvm-svn: 126593
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
specifiers such as
typename T::template apply<U>
Previously, we would turn T::template apply<U> into a
TemplateSpecializationType. Then, we'd reprocess that
TemplateSpecializationType and turn it into either a
TemplateSpecializationType wrapped in an ElaboratedType (when we could
resolve "apply" to a template declaration) or a
DependentTemplateSpecializationType. We now produce the same ASTs but
without generating the intermediate TemplateSpecializationType.
The end goal here is to avoid generating TemplateSpecializationTypes
with dependent template-names, ever. We're not there yet.
llvm-svn: 126589
|
| |
|
|
|
|
|
|
|
|
|
| |
This successfully performs constructor lookup and verifies that a
delegating initializer is the only initializer present.
This does not perform loop detection in the initialization, but it also
doesn't codegen delegating constructors at all, so this won't cause
runtime infinite loops yet.
llvm-svn: 126552
|
| |
|
|
|
|
|
| |
don't let calls to such functions go down the normal type-checking path.
Test this out with __builtin_classify_type and __builtin_constant_p.
llvm-svn: 126539
|
| |
|
|
|
|
| |
where ever such attribute causes an error diagnostic.
llvm-svn: 126509
|
| |
|
|
|
|
|
| |
DependentScopeDeclRefExpr. Plus, give NestedNameSpecifierLoc == and !=
operators, since we're going to need 'em elsewhere.
llvm-svn: 126508
|
| |
|
|
|
|
|
|
|
|
| |
marking selected overloads into the callers. This allows a few callers
to skip it altogether (they would have anyways because they weren't
interested in successful overloads) or defer until after further checks
take place much like the check required for PR9323 to avoid marking
unused copy constructors.
llvm-svn: 126503
|
| |
|
|
|
|
| |
// rdar://9046492
llvm-svn: 126499
|
| |
|
|
|
|
|
|
| |
pseudo-destructor expressions. Also, clean up some
template-instantiation and type-checking issues with
pseudo-destructors.
llvm-svn: 126498
|
| |
|
|
|
|
| |
aliases.
llvm-svn: 126496
|
| |
|
|
| |
llvm-svn: 126489
|
| |
|
|
|
|
| |
NestedNameSpecifierLoc handling.
llvm-svn: 126486
|
| |
|
|
|
|
| |
instantiation of using declarations (all three forms).
llvm-svn: 126485
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
declarations as referenced when in fact we're not going to even form
a call in the AST. This is significant because we attempt to allow as an
extension classes with intentionally private and undefined copy
constructors to have temporaries bound to references, and so shouldn't
warn about the lack of definition for that copy constructor when the
class is internal.
Doug, John wasn't really satisfied with the presence of overloading at
all. This is a stop-gap and there may be a better solution. If you can
give me some hints for how you'd prefer to see this solved, I'll happily
switch things over.
llvm-svn: 126480
|
| |
|
|
| |
llvm-svn: 126475
|
| |
|
|
|
|
|
| |
tag definitions. Also, add support for template instantiation of
NestedNameSpecifierLocs.
llvm-svn: 126470
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
UnresolvedUsingValueDecl to use NestedNameSpecifierLoc rather than the
extremely-lossy NestedNameSpecifier/SourceRange pair it used to use,
improving source-location information.
Various infrastructure updates to support NestedNameSpecifierLoc:
- AST/PCH (de-)serialization
- Recursive AST visitor
- libclang traversal (including the first tests of this
functionality)
llvm-svn: 126459
|
| |
|
|
|
|
|
|
| |
never can be a real security issue.
Fixes PR 9314.
llvm-svn: 126447
|
| |
|
|
|
|
|
|
|
|
|
|
| |
nested-name-specifiers throughout the parser, and provide a new class
(NestedNameSpecifierLoc) that contains a nested-name-specifier along
with its type-source information.
Right now, this information is completely useless, because we don't
actually store the source-location information anywhere in the
AST. Call this Step 1/N.
llvm-svn: 126391
|
| |
|
|
|
|
| |
Add an interface for last resort, unqualified lookup. It can provide results for unqualified lookup when Sema fails to find anything itself.
llvm-svn: 126387
|
| |
|
|
|
|
|
| |
_Bool is 1 bit, not 8. This fixes an assertion on the testcase, which is
PR9304 and rdar://9045501.
llvm-svn: 126368
|
| |
|
|
|
|
|
| |
unneeded allocation of an empty StringLiteral when these don't have
a message.
llvm-svn: 126364
|
| |
|
|
|
|
|
|
| |
way it keeps track of namespaces. Previously, we would map from the
namespace alias to its underlying namespace when building a
nested-name-specifier, losing source information in the process.
llvm-svn: 126358
|
| |
|
|
|
|
| |
nested-name-specifier and source range to be set at the same time.
llvm-svn: 126347
|
| |
|
|
|
|
|
|
|
| |
with another component in the nested-name-specifiers, updating its
representation (a NestedNameSpecifier) and source-location information
(currently a SourceRange) simultaneously. This is groundwork for
adding source-location information to nested-name-specifiers.
llvm-svn: 126346
|
| |
|
|
|
|
|
|
| |
don't seem to have been covered by our tests previously.
This should fix bootstrap failure.
llvm-svn: 126345
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
expressions. Consider the code:
int64_t i = 10 << 30;
This compiles fine, but most developers expect it to produce the value
for 10 gigs, not -2 gigs. This is actually undefined behavior because
the LHS is a signed integer type.
The warning is currently gated behind -Wshift-overflow.
There is a special case where only the sign bit is overridden that gets
a custom error message and is by default ignored. This case is much less
likely to cause observed buggy behavior, it's just undefined behavior
according to the spec. This warning can be enabled with
-Wshift-sign-overflow.
Original patch by Oleg Slezberg, with style tweaks and some correctness
fixes by me.
llvm-svn: 126342
|
| |
|
|
| |
llvm-svn: 126341
|
| |
|
|
|
|
|
|
|
|
| |
several ways. We now warn for more of the return types, and correctly
locate the ignored ones. Also adds fix-it hints to remove the ignored
qualifiers. Fixes much of PR9058, although not all of it.
Patch by Hans Wennborg, a couple of minor style tweaks from me.
llvm-svn: 126321
|
| |
|
|
| |
llvm-svn: 126303
|
| |
|
|
| |
llvm-svn: 126292
|
| |
|
|
|
|
|
|
|
|
| |
related code is reachable. This suppresses some
diagnostics that occur in unreachable code (e.g., -Warray-bound).
We only pay the cost of doing the reachability analysis when we issue one of these diagnostics.
llvm-svn: 126290
|
| |
|
|
| |
llvm-svn: 126288
|
| |
|
|
|
|
| |
Sema::PopBlockOrFunctionScope(). No real functionality change.
llvm-svn: 126287
|
| |
|
|
|
|
|
|
|
| |
code the diagnostic is associated with.
This Stmt* is unused, but we will use it shortly for pruning diagnostics associated
with unreachable code.
llvm-svn: 126286
|
| |
|
|
|
|
| |
using basic dataflow to suppress warnings on unreachable array bounds checks.
llvm-svn: 126285
|
| |
|
|
|
|
| |
in the same declaration group in the template instantiation case.
llvm-svn: 126279
|
| |
|
|
|
|
|
| |
mostly just shuffles various possibilities for recovery into a more
straightforward order, but also unifies a couple of diagnostics.
llvm-svn: 126266
|
| |
|
|
|
|
|
| |
FunctionProtoTypeLoc with NULL function parameter types, which can
occur in invalid code. Fixes PR9247 / <rdar://problem/9037911>.
llvm-svn: 126262
|
| |
|
|
|
|
| |
array from a constant array compound literal. Fixes PR9261.
llvm-svn: 126230
|
| |
|
|
|
|
| |
enumeration types. Fixes <rdar://problem/8559831>.
llvm-svn: 126183
|
| |
|
|
|
|
| |
diagnostics suggesting they are missing.
llvm-svn: 126174
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* 'auto' was being rejected on abstract-declarators with trailing return
types and on typedefs with trailing return types. 'auto' is always
allowed in these cases. This was found while testing the fix for PR 9278.
* A very poor diagnostic was being issued for auto (f() -> int): "return
type must be 'auto', not 'auto'". This is closely related to PR 9060.
* Trailing return type handling was happening slightly too late,
resulting in the checks for functions returning arrays and functions
returning functions being missed.
llvm-svn: 126166
|
| |
|
|
|
|
|
| |
protocols do not match with method implementation.
// rdar://7076235
llvm-svn: 126162
|
| |
|
|
|
|
|
|
|
|
| |
This actually rules out too much, since it also catches typedefs for pointers to functions with trailing return types:
typedef auto (*F)() -> int;
Fix for that (and the same issue in all abstract-declarators) to follow shortly.
llvm-svn: 126153
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the mismatch is due to a larger input operand that is
a constant, truncate it down to the size of the output. This
allows us to accept some cases in the linux kernel and elsewhere.
Pedantically speaking, we generate different code than GCC, though
I can't imagine how it would matter:
Clang:
movb $-1, %al
frob %al
GCC:
movl $255, %eax
frob %al
llvm-svn: 126148
|