Commit Graph

8 Commits

Author SHA1 Message Date
Rafael Espindola 568586ff22 Fix PR6618.
If a struct has an invalid field, mark it as invalid. Also avoid producing
errors about incomplete types that are invalid.

llvm-svn: 99150
2010-03-21 22:56:43 +00:00
Daniel Dunbar 8fbe78f6fc Update tests to use %clang_cc1 instead of 'clang-cc' or 'clang -cc1'.
- This is designed to make it obvious that %clang_cc1 is a "test variable"
   which is substituted. It is '%clang_cc1' instead of '%clang -cc1' because it
   can be useful to redefine what gets run as 'clang -cc1' (for example, to set
   a default target).

llvm-svn: 91446
2009-12-15 20:14:24 +00:00
Eli Friedman d0e8de2cd8 Move RequireCompleteType requirement for fields early into ActOnField so that
subsequent code which depends on a complete type does the right thing.

llvm-svn: 90727
2009-12-07 00:22:08 +00:00
Chris Lattner edfa8d4557 Change SemaType's "GetTypeForDeclarator" and "ConvertDeclSpecToType" to
always return a non-null QualType + error bit.  This fixes a bunch of 
cases that didn't check for null result (and could thus crash) and eliminates
some crappy code scattered throughout sema.

This also improves the diagnostics in the recursive struct case to eliminate
a bogus second error.  It also cleans up the case added to function.c by forming
a proper function type even though the declarator is erroneous, allowing the
parameter to be added to the function.  Before:

t.c:2:1: error: unknown type name 'unknown_type'
unknown_type f(void*P)
^
t.c:4:3: error: use of undeclared identifier 'P'
  P+1;
  ^

After:
t.c:2:1: error: unknown type name 'unknown_type'
unknown_type f(void*P)
^

llvm-svn: 70023
2009-04-25 08:47:54 +00:00
Daniel Dunbar a45cf5b6b0 Rename clang to clang-cc.
Tests and drivers updated, still need to shuffle dirs.

llvm-svn: 67602
2009-03-24 02:24:46 +00:00
Douglas Gregor e62c0a45dd Improve merging of function declarations. Specifically:
- 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
2009-02-24 01:23:02 +00:00
Chris Lattner d13b8b55ca fix rdar://6611778, a redefinition of an interface was causing an
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
2009-02-23 22:00:08 +00:00
Douglas Gregor 82ac25e4a7 Unify the code for defining tags in C and C++, so that we always
introduce a Scope for the body of a tag. This reduces the number of
semantic differences between C and C++ structs and unions, and will
help with other features (e.g., anonymous unions) in C. Some important
points:

  - Fields are now in the "member" namespace (IDNS_Member), to keep
    them separate from tags and ordinary names in C. See the new test
    in Sema/member-reference.c for an example of why this matters. In
    C++, ordinary and member name lookup will find members in both the
    ordinary and member namespace, so the difference between
    IDNS_Member and IDNS_Ordinary is erased by Sema::LookupDecl (but
    only in C++!). 
  - We always introduce a Scope and push a DeclContext when we're
    defining a tag, in both C and C++. Previously, we had different
    actions and different Scope/CurContext behavior for enums, C
    structs/unions, and C++ structs/unions/classes. Now, it's one pair
    of actions. (Yay!)

There's still some fuzziness in the handling of struct/union/enum
definitions within other struct/union/enum definitions in C. We'll
need to do some more cleanup to eliminate some reliance on CurContext
before we can solve this issue for real. What we want is for something
like this:

  struct X {
    struct T { int x; } t;
  };

to introduce T into translation unit scope (placing it at the
appropriate point in the IdentifierResolver chain, too), but it should
still have struct X as its lexical declaration
context. PushOnScopeChains isn't smart enough to do that yet, though,
so there's a FIXME test in nested-redef.c

llvm-svn: 61940
2009-01-08 20:45:30 +00:00