| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
| |
llvm-svn: 91067
|
| |
|
|
|
|
| |
in objective-c++ mode.
llvm-svn: 91059
|
| |
|
|
|
|
|
|
| |
declaration. Rename note_using_decl to note_using, which is possibly less confusing.
Add a test for non-class-scope using decl collisions and be sure to note the case
we can't diagnose yet.
llvm-svn: 91057
|
| |
|
|
|
|
| |
into its own helper method. No change in functionality.
llvm-svn: 91056
|
| |
|
|
|
|
| |
a type currently being defined, from Nicola Gigante!
llvm-svn: 91052
|
| |
|
|
| |
llvm-svn: 91050
|
| |
|
|
|
|
|
|
|
|
|
| |
declarations. There
are a couple of O(n^2) operations in this, some analogous to the usual O(n^2)
redeclaration problem and some not. In particular, retroactively removing
shadow declarations when they're hidden by later decls is pretty unfortunate.
I'm not yet convinced it's worse than the alternative, though.
llvm-svn: 91045
|
| |
|
|
| |
llvm-svn: 91044
|
| |
|
|
|
|
| |
currently mangle them the same way as gcc does.
llvm-svn: 91042
|
| |
|
|
| |
llvm-svn: 91041
|
| |
|
|
|
|
| |
a better diagnostic in the second example.
llvm-svn: 91040
|
| |
|
|
| |
llvm-svn: 91039
|
| |
|
|
|
|
|
| |
to use ColonProtectionRAIIObject in the C codepath even though it
won't matter for consistency.
llvm-svn: 91037
|
| |
|
|
| |
llvm-svn: 91036
|
| |
|
|
|
|
| |
during throw to deallocate the exception object. WIP.
llvm-svn: 91035
|
| |
|
|
| |
llvm-svn: 91032
|
| |
|
|
| |
llvm-svn: 91027
|
| |
|
|
| |
llvm-svn: 91026
|
| |
|
|
| |
llvm-svn: 91024
|
| |
|
|
|
|
|
| |
TODOs for other classes that could be moved out of Parser.h. I don't plan
to do these in the near term though.
llvm-svn: 91023
|
| |
|
|
| |
llvm-svn: 91016
|
| |
|
|
|
|
|
| |
to be a bool in Parser that is twiddled by the ColonProtectionRAIIObject
class. No functionality change.
llvm-svn: 91014
|
| |
|
|
| |
llvm-svn: 91012
|
| |
|
|
| |
llvm-svn: 91008
|
| |
|
|
| |
llvm-svn: 91006
|
| |
|
|
|
|
| |
of dirty data around.
llvm-svn: 91002
|
| |
|
|
| |
llvm-svn: 91001
|
| |
|
|
| |
llvm-svn: 91000
|
| |
|
|
| |
llvm-svn: 90998
|
| |
|
|
| |
llvm-svn: 90997
|
| |
|
|
| |
llvm-svn: 90996
|
| |
|
|
|
|
| |
(fixes radar 7457534).
llvm-svn: 90995
|
| |
|
|
| |
llvm-svn: 90994
|
| |
|
|
|
|
| |
We still aren't handling them correctly; I've added to failing test cases to test/Analysis/NSString-failed-cases.m that should pass and then be merged in to test/Analysis/NSString.m.
llvm-svn: 90993
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
new notion of an "initialization sequence", which encapsulates the
computation of the initialization sequence along with diagnostic
information and the capability to turn the computed sequence into an
expression. At present, I've only switched one CheckReferenceInit
callers over to this new mechanism; more will follow.
Aside from (hopefully) being much more true to the standard, the
diagnostics provided by this reference-initialization code are a bit
better than before. Some examples:
p5-var.cpp:54:12: error: non-const lvalue reference to type 'struct
Derived'
cannot bind to a value of unrelated type 'struct Base'
Derived &dr2 = b; // expected-error{{non-const lvalue reference to
...
^ ~
p5-var.cpp:55:9: error: binding of reference to type 'struct Base' to
a value of
type 'struct Base const' drops qualifiers
Base &br3 = bc; // expected-error{{drops qualifiers}}
^ ~~
p5-var.cpp:57:15: error: ambiguous conversion from derived class
'struct Diamond' to base class 'struct Base':
struct Diamond -> struct Derived -> struct Base
struct Diamond -> struct Derived2 -> struct Base
Base &br5 = diamond; // expected-error{{ambiguous conversion from
...
^~~~~~~
p5-var.cpp:59:9: error: non-const lvalue reference to type 'long'
cannot bind to
a value of unrelated type 'int'
long &lr = i; // expected-error{{non-const lvalue reference to type
...
^ ~
p5-var.cpp:74:9: error: non-const lvalue reference to type 'struct
Base' cannot
bind to a temporary of type 'struct Base'
Base &br1 = Base(); // expected-error{{non-const lvalue reference to
...
^ ~~~~~~
p5-var.cpp:102:9: error: non-const reference cannot bind to bit-field
'i'
int & ir1 = (ib.i); // expected-error{{non-const reference cannot
...
^ ~~~~~~
p5-var.cpp:98:7: note: bit-field is declared here
int i : 17; // expected-note{{bit-field is declared here}}
^
llvm-svn: 90992
|
| |
|
|
| |
llvm-svn: 90991
|
| |
|
|
|
|
| |
(fixes radar 7457109).
llvm-svn: 90986
|
| |
|
|
| |
llvm-svn: 90982
|
| |
|
|
|
|
| |
was not needed (fixes radar 7453430).
llvm-svn: 90981
|
| |
|
|
| |
llvm-svn: 90974
|
| |
|
|
| |
llvm-svn: 90968
|
| |
|
|
|
|
|
|
| |
Otherwise, even when real evaluation occurs, the previous fake auto
transitions would still be in the destination set, causing fake state
bifurcation.
llvm-svn: 90967
|
| |
|
|
|
|
|
|
|
|
|
|
| |
"integer promotion" type associated with an enum decl, and use this type to
determine which type to promote to. This type obeys C++ [conv.prom]p2 and
is therefore generally signed unless the range of the enumerators forces
it to be unsigned.
Kills off a lot of false positives from -Wsign-compare in C++, addressing
rdar://7455616
llvm-svn: 90965
|
| |
|
|
|
|
|
|
| |
instead of the ElementRegion obtained from casts.
Test cast: the leak cannot occur bacause the true branch cannot be taken.
llvm-svn: 90964
|
| |
|
|
| |
llvm-svn: 90961
|
| |
|
|
| |
llvm-svn: 90953
|
| |
|
|
|
|
| |
repeatedly.
llvm-svn: 90952
|
| |
|
|
|
|
| |
PerformObjectArgumentInitialization from BuildCXXMemberCallExpr.
llvm-svn: 90950
|
| |
|
|
| |
llvm-svn: 90949
|
| |
|
|
|
|
| |
than one heirarchy of classes. John, please review.
llvm-svn: 90948
|