Steve Naroff [Mon, 13 Apr 2009 17:58:46 +0000 (17:58 +0000)]
Change diagnostic as a result of researching <rdar://problem/6779809> missing interface name in "error: cannot declare variable inside a class, protocol or category ''.
Since ObjC 2.0 class "extensions" have a null name, the diagnostic above is actually "correct". Nevertheless, it is confusing. Decided to remove the name entirely (from my perspective, it didn't add any value). Also simplified the text of the diagnostic a bit.
Douglas Gregor [Mon, 13 Apr 2009 17:12:42 +0000 (17:12 +0000)]
Make the reading of the line table from a PCH file more robust against
the unlikely event that the filename IDs in the stored line table end
up being different from the filename IDs in the newly-created line
table.
Douglas Gregor [Mon, 13 Apr 2009 15:14:38 +0000 (15:14 +0000)]
Make the selection of type declarations in Sema::getTypeName
deterministic when faced with an ambiguity. This eliminates the
annoying test/SemaCXX/using-directive.cpp failure.
Chris Lattner [Sun, 12 Apr 2009 22:23:27 +0000 (22:23 +0000)]
Fix some C++ error recovery problems in init declarator parsing
that I noticed working on other things.
Instead of emitting:
t2.cc:1:8: error: use of undeclared identifier 'g'
int x(*g);
^
t2.cc:1:10: error: expected ')'
int x(*g);
^
t2.cc:1:6: note: to match this '('
int x(*g);
^
We now only emit:
t2.cc:1:7: warning: type specifier missing, defaults to 'int'
int x(*g);
^
Note that the example in SemaCXX/nested-name-spec.cpp:f4 is still
not great, we now produce both of:
void f4(undef::C); // expected-error {{use of undeclared identifier 'undef'}} \
expected-error {{variable has incomplete type 'void'}}
The second diagnostic should be silenced by something getting marked invalid.
I don't plan to fix this though.
Chris Lattner [Sun, 12 Apr 2009 21:49:30 +0000 (21:49 +0000)]
Diagnose invalid uses of tagged types with a missing tag. For example, in:
struct xyz { int y; };
enum abc { ZZZ };
static xyz b;
abc c;
we used to produce:
t2.c:4:8: error: unknown type name 'xyz'
static xyz b;
^
t2.c:5:1: error: unknown type name 'abc'
abc c;
^
we now produce:
t2.c:4:8: error: use of tagged type 'xyz' without 'struct' tag
static xyz b;
^
struct
t2.c:5:1: error: use of tagged type 'abc' without 'enum' tag
abc c;
^
enum
GCC produces the normal:
t2.c:4: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘b’
t2.c:5: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘c’
Chris Lattner [Sun, 12 Apr 2009 20:51:10 +0000 (20:51 +0000)]
fix a valgrind problem I noticed while developing another patch,
if a decl is invalid, it isn't added to the Decls array, so we
need to pass in Decls.size() to avoid reading uninit memory.
Chris Lattner [Sun, 12 Apr 2009 20:42:31 +0000 (20:42 +0000)]
Implement the first set of changes for PR3963 and rdar://6759604,
which tries to do better error recovery when it is "obvious" that an
identifier is a mis-typed typename. In this case, we try to parse
it as a typename instead of as the identifier in a declarator, which
gives us several options for better error recovery and immediately
makes diagnostics more useful. For example, we now produce:
t.c:4:8: error: unknown type name 'foo_t'
static foo_t a = 4;
^
instead of:
t.c:4:14: error: invalid token after top level declarator
static foo_t a = 4;
^
Also, since we now parse "a" correctly, we make a decl for it,
preventing later uses of 'a' from emitting things like:
t.c:12:20: error: use of undeclared identifier 'a'
int bar() { return a + b; }
^
I'd really appreciate any scrutiny possible on this, it
is a tricky area.
Chris Lattner [Sun, 12 Apr 2009 20:09:42 +0000 (20:09 +0000)]
a few cleanups to StatementCreatesScope: unnest the whole thing,
exit at the first decl found that creates a scope, don't evaluate
decl_end() every iteration.
Sebastian Redl [Sun, 12 Apr 2009 17:16:29 +0000 (17:16 +0000)]
Parse deleted member functions. Parsing member declarations goes through a different code path that I forgot previously.
Implement the rvalue reference overload dance for returning local objects. Returning a local object first tries to find a move constructor now.
The error message when no move constructor is defined (or is not applicable) and the copy constructor is deleted is quite ugly, though.
Chris Lattner [Sun, 12 Apr 2009 08:43:13 +0000 (08:43 +0000)]
Fix rdar://6771034: don't warn on use of forward declared protocol in protocol
list of another protocol definition. This warning is very noisy and GCC doesn't
produce it so existing code doesn't expect it.
Chris Lattner [Sat, 11 Apr 2009 21:15:38 +0000 (21:15 +0000)]
now that we have an identifier table in the PCH file, finish hooking up
macro deserialization. We now correctly install II's in tokens, handle
function-like macros, etc.
Chris Lattner [Sat, 11 Apr 2009 20:14:49 +0000 (20:14 +0000)]
improve location info for property stuff. In a property like this:
@property int x;
associate the location of X with the property decl, not the location
of the @. Also, pass this info along to the synthesized ParmVarDecls
so that redefinition and other diagnostics can use it. This eliminates
a fixme.
Chris Lattner [Sat, 11 Apr 2009 19:58:42 +0000 (19:58 +0000)]
improve the 'conflicting types' diagnostics to include correct location info, now
that it is plumbed through Sema. On a file from growl, we used to emit:
t.mi:107059:1: warning: conflicting types for 'removePluginHandler:forPluginTypes:'
- (void) removePluginHandler:(id <GrowlPluginHandler>)handler forPluginTypes:(NSSet *)extensions {
^
t.mi:105280:1: note: previous definition is here
- (void) removePluginHandler:(id <NSObject>)handler forPluginTypes:(NSSet *)types;
^
now we produce:
t.mi:107059:55: warning: conflicting parameter types in implementation of 'removePluginHandler:forPluginTypes:': 'id<NSObject>' vs 'id<GrowlPluginHandler>'
- (void) removePluginHandler:(id <GrowlPluginHandler>)handler forPluginTypes:(NSSet *)extensions {
^
t.mi:105280:45: note: previous definition is here
- (void) removePluginHandler:(id <NSObject>)handler forPluginTypes:(NSSet *)types;
^
We still don't have proper loc info for properties, hence the FIXME.
Chris Lattner [Sat, 11 Apr 2009 19:27:54 +0000 (19:27 +0000)]
fix blocks to reject objc interfaces returned by value. Also,
a block without a prototype should still coerce a return in it to
use the declared return type.
Chris Lattner [Sat, 11 Apr 2009 19:08:56 +0000 (19:08 +0000)]
Improve the 'cannot pass objc interface by value' diagnostic:
1) improve localizability by not passing english strings in.
2) improve location for arguments.
3) print the objc type being passed.
Before:
method-bad-param.m:15:1: error: Objective-C type cannot be passed by value
-(void) my_method:(foo) my_param
^
after:
method-bad-param.m:15:25: error: Objective-C interface type 'foo' cannot be passed by value
-(void) my_method:(foo) my_param
^
Chris Lattner [Sat, 11 Apr 2009 18:57:04 +0000 (18:57 +0000)]
change the interface to ActOnMethodDeclaration to pass down argument
information in a little struct instead of individually. While we're
at it, add per-argument loc info and attribute info.
Chris Lattner [Sat, 11 Apr 2009 18:48:18 +0000 (18:48 +0000)]
sink abstract typedefs like Action::ExprTy from the Action class
down to the ActionBase class. This eliminates dependencies of (e.g.)
DeclSpec.h on Action.h, meaning that action.h can now include these
headers and use their types directly in the actions interfaces.
This is a refactoring to support a future change, no functionality
change.
Douglas Gregor [Sat, 11 Apr 2009 00:14:32 +0000 (00:14 +0000)]
Store unique IDs for identifiers in the PCH file. Use some bitmangling
so that we only need to perform the lookup and identifier resolution
once per identifier in the PCH file.
Douglas Gregor [Fri, 10 Apr 2009 23:10:45 +0000 (23:10 +0000)]
Compare the predefines buffer in the PCH file with the predefines
buffer generated for the current translation unit. If they are
different, complain and then ignore the PCH file. This effectively
checks for all compilation options that somehow would affect
preprocessor state (-D, -U, -include, the dreaded -imacros, etc.).
When we do accept the PCH file, throw away the contents of the
predefines buffer rather than parsing them, since all of the results
of that parsing are already stored in the PCH file. This eliminates
the ugliness with the redefinition of __builtin_va_list, among other
things.
Chris Lattner [Fri, 10 Apr 2009 22:13:17 +0000 (22:13 +0000)]
do a dance with predefines, and finally enable reading of macros from
PCH. This works now, except for limitations not being able to do things
with identifiers. The basic example in the testcase works though.
Chris Lattner [Fri, 10 Apr 2009 21:58:23 +0000 (21:58 +0000)]
move a bunch of code for initializing the predefines buffer out of Preprocessor.cpp
into clang-cc.cpp. This makes it so clang-cc constructs the *entire* predefines
buffer, not just half of it. A bonus of this is that we get to kill a copy
of DefineBuiltinMacro.
Chris Lattner [Fri, 10 Apr 2009 21:41:48 +0000 (21:41 +0000)]
add support for reading macros. This does all the reading (with a bunch of
fixme's, e.g. for tokens with identifiers) but does not actually install
them. Some details with the predefines buffer needs to be sorted out first.
Add arbitrary "tags" to ProgramPoints. While this fattens up ProgramPoint even
more, it gives us a tremendous amount of flexibility for extending the analyzer
to handle arbitrary program points.
Douglas Gregor [Fri, 10 Apr 2009 20:39:37 +0000 (20:39 +0000)]
Implement serialization/deserialization of LangOptions in the PCH
file. When de-serializing LangOptions, we check that the
currently-provided language options are consistent with the options
used to compile the PCH file. If they are not, we emit a diagnostic
and ignore the PCH file.
Daniel Dunbar [Fri, 10 Apr 2009 20:26:50 +0000 (20:26 +0000)]
Internal variables could mistakenly have "hidden" visibility when
their emission was deferred.
- <rdar://problem/6775234> variables with internal linkage should not
be exposed with -fvisibility=hidden.
projects / clang / log