The goal of this sugar node is to be able to look at an arbitrary
FunctionType and tell if any of the parameters were decayed from an
array or function type. Ultimately this is necessary to implement
Microsoft's C++ name mangling scheme, which mangles decayed arrays
differently from normal pointers.
Reviewers: rsmith
Differential Revision: http://llvm-reviews.chandlerc.com/D1014
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@184763 91177308-0d34-0410-b5e6-96231b3b80d8
multiple name lookup results in C/Objective-C. Fixes a regression a
caused in r147533, found by Enea Zaffanella!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148154 91177308-0d34-0410-b5e6-96231b3b80d8
- 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).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91446 91177308-0d34-0410-b5e6-96231b3b80d8
scheme to be more useful.
The new scheme introduces a set of categories that should be more
readable, and also reflects what we want to consider as an extension
more accurately. Specifically, it makes the "what is a keyword"
determination accurately reflect whether the keyword is a GNU or
Microsoft extension.
I also introduced separate flags for keyword aliases; this is useful
because the classification of the aliases is mostly unrelated to the
classification of the original keyword.
This patch treats anything that's in the implementation
namespace (prefixed with "__", or "_X" where "X" is any upper-case
letter) as a keyword without marking it as an extension. This is
consistent with the standards in that an implementation is allowed to define
arbitrary extensions in the implementation namespace without violating
the standard. This gets rid of all the nasty "extension used" warnings
for stuff like __attribute__ in -pedantic mode. We still warn for
extensions outside of the the implementation namespace, like typeof.
If someone wants to implement -Wextensions or something like that, we
could add additional information to the keyword table.
This also removes processing for the unused "Boolean" language option;
such an extension isn't supported on any other C implementation, so I
don't see any point to adding it.
The changes to test/CodeGen/inline.c are required because previously, we
weren't actually disabling the "inline" keyword in -std=c89 mode.
I'll remove Boolean and NoExtensions from LangOptions in a follow-up
commit.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@70281 91177308-0d34-0410-b5e6-96231b3b80d8
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)
^
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@70023 91177308-0d34-0410-b5e6-96231b3b80d8
parameters in a functiondecl, even if the decl is invalid and has a confusing
Declarator. On the testcase, we now emit one beautiful diagnostic:
t.c:2:1: error: unknown type name 'unknown_type'
unknown_type f(void*)
^
GCC 4.0 produces:
t.c:2: error: syntax error before ‘f’
t.c: In function ‘f’:
t.c:2: error: parameter name omitted
and GCC 4.2:
t.c:2: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘f’
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@70016 91177308-0d34-0410-b5e6-96231b3b80d8
typedef void foo(void);
We get a typedef for a functiontypeproto with no arguments, not
one with one argument and type void. This means the code being
removed in SemaDecl is dead.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@70013 91177308-0d34-0410-b5e6-96231b3b80d8
extern. Previously we would warn about it and ignore the attribute.
This is incorrect, it should be handled as a c89 "extern inline"
function. Many thanks to Matthieu Castet for pointing this out and
beating me over the head until I got it.
PR3988: extern inline function are not externally visible
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@69756 91177308-0d34-0410-b5e6-96231b3b80d8
a dummy *function* type when it is recovering and knows it needs
a function. rdar://6802350 - clang crash on invalid input
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@69374 91177308-0d34-0410-b5e6-96231b3b80d8
incomplete types. RequireCompleteType is needed when the type may be
completed by instantiating a template.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67643 91177308-0d34-0410-b5e6-96231b3b80d8
- 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"
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65360 91177308-0d34-0410-b5e6-96231b3b80d8
special action, inside function prototype scope. This avoids confusion
when we try to inject these parameters into the scope of the function
body before the function itself has been added to the surrounding
scope. Fixes <rdar://problem/6097326>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@62849 91177308-0d34-0410-b5e6-96231b3b80d8
Fix PR2790 by making a warning an EXTWARN instead of EXTENSION.
Add a new EXTENSION warning for "return (some void expression);"
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@61187 91177308-0d34-0410-b5e6-96231b3b80d8
int foobar(int);
int foobar() {}
which requires ifdef'ing out a testcase in predefined-function.c.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@47236 91177308-0d34-0410-b5e6-96231b3b80d8
missing. Otherwise, it is an implicit int case, which is valid in c90 and invalid
elsewhere, but accepted as an extension.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@46938 91177308-0d34-0410-b5e6-96231b3b80d8
Tightening up this routine forced tweaks to Sema::CheckSubtractionOperands() and Sema::CheckCompareOperands(). For example, they both need to operate on the unqualified pointee...
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@46522 91177308-0d34-0410-b5e6-96231b3b80d8
proto and function type without proto. It would never call
'functionTypesAreCompatible' because they have different type classes.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@45952 91177308-0d34-0410-b5e6-96231b3b80d8
Nathan Sidwell