while I was at it. There are still a lot of diagnostics missing from
this code, and it isn't completely correct for anything other than x86, but
it should work correctly on x86 for valid cases.
llvm-svn: 65935
need them to evaluate redeclarations or call a function that hasn't
already been declared. We now keep a DenseMap of these locally-scoped
declarations so that they are not visible but can be quickly found,
e.g., when we're looking for previous declarations or before we go
ahead and implicitly declare a function that's being called. Fixes
PR3672.
llvm-svn: 65792
- Move the 'LabelMap' from Sema to Scope. To avoid layering problems, the second element is now a 'StmtTy *', which makes the LabelMap a bit more verbose to deal with.
- Add 'ActiveScope' to Sema. Managed by ActOnStartOfFunctionDef(), ObjCActOnStartOfMethodDef(), ActOnBlockStmtExpr().
- Changed ActOnLabelStmt(), ActOnGotoStmt(), ActOnAddrLabel(), and ActOnFinishFunctionBody() to use the new ActiveScope.
- Added FIXME to workaround in ActOnFinishFunctionBody() (for dealing with C++ nested functions).
llvm-svn: 65694
As far as I know, this catches all cases of jumping into the scope of a
variable with a variably modified type (excluding statement
expressions) in C. This is missing some stuff we probably want to check
(other kinds of variably modified declarations, statement expressions,
indirect gotos/addresses of labels in a scope, ObjC @try/@finally, cleanup
attribute), the diagnostics aren't very good, and it's not particularly
efficient, but it's a decent start.
This patch is a slightly modified version of the patch I attached to
PR3259, and it fixes that bug. I was sort of planning on improving
it, but I think it's okay as-is, especially since it looks like CodeGen
doesn't have any use for this sort of data structure. The only
significant change I can think of from the version I attached to PR3259
is that this version skips running the checking code when a function
doesn't contain any labels.
This patch doesn't cover case statements, which also need similar
checking; I'm not sure how we should deal with that. Extending the goto
checking to also check case statements wouldn't be too hard; it's just a
matter of keeping track of the scope of the closest switch and checking that
the scope of every case is the same as the scope of the switch. That said,
it would likely be a performance hit to run this check on every
function (it's an extra pass over the entire function), so we probably want
some other solution.
llvm-svn: 65678
in C89 mode. This makes it enabled by default instead of only enabled with
-pedantic. Clang defaults to c99 mode, so people will see this more often
than with GCC, but they can always use -std=c89 if they really want c89.
llvm-svn: 65647
normal expression, and change Evaluate and IRGen to evaluate it like a
normal expression. This simplifies the code significantly, and fixes
PR3396.
llvm-svn: 65622
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
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
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
- 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
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
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
This prevents emitting diagnostics which are almost certainly useless.
(Note that the test is checking that we emit only one diagnostic.)
llvm-svn: 65101
information about types. We often print diagnostics where we say
"foo_t" is bad, but the user doesn't know how foo_t is declared
(because it is a typedef). Fix this by expanding sugar when present
in a diagnostic (and not one of a few special cases, like vectors).
Before:
t.m:5:2: error: invalid operands to binary expression ('typeof(P)' and 'typeof(F)')
MAX(P, F);
^~~~~~~~~
t.m:1:78: note: instantiated from:
#define MAX(A,B) ({ __typeof__(A) __a = (A); __typeof__(B) __b = (B); __a < __b ? __b : __a; })
^
After:
t.m:5:2: error: invalid operands to binary expression ('typeof(P)' (aka 'struct mystruct') and 'typeof(F)' (aka 'float'))
MAX(P, F);
^~~~~~~~~
t.m:1:78: note: instantiated from:
#define MAX(A,B) ({ __typeof__(A) __a = (A); __typeof__(B) __b = (B); __a < __b ? __b : __a; })
^
llvm-svn: 65081
Daniel Dunbar