Since that point is now long gone, we should rename LexerToken to
Token, as it is the only kind of token we have.

llvm-svn: 40105

llvm-svn: 40104

fileid/offset pair, it now contains a bit discriminating between
mapped locations and file locations.  This separates the tables for
macros and files in SourceManager, and allows better separation of
concepts in the rest of the compiler.  This allows us to have *many*
macro instantiations before running out of 'addressing space'.

This is also more efficient, because testing whether something is a
macro expansion is now a bit test instead of a table lookup (which
also used to require having a srcmgr around, now it doesn't).

This is fully functional, but there are several refinements and
optimizations left.

llvm-svn: 40103

llvm-svn: 40068

We still need to do sematic analysis (and implement initializers), however this 
should complete the parsing & ast building for compound literals.

llvm-svn: 40067

#define t(x) #x
t(a
c)

to "a c", not "ac".

llvm-svn: 40060

llvm-svn: 40037

Work towards fixing crasher with compound literals...

Before this commit, we crashed in ParseBinOp...

[dylan:~/llvm/tools/clang] admin% ../../Debug/bin/clang -parse-ast-check compound_literal.c
SemaExpr.cpp:1298: failed assertion `(rhs != 0) && "ParseBinOp(): missing right expression"'

With this commit, we still crash in the newly added action ParseCompoundLiteral (which is progress:-)

[dylan:~/llvm/tools/clang] admin% ../../Debug/bin/clang -parse-ast-check compound_literal.c
SemaExpr.cpp:478: failed assertion `(Op != 0) && "ParseCompoundLiteral(): missing expression"'

The crash go away once the actions return AST nodes. I will do this in a separate commit.

llvm-svn: 40032

return a null type.  If there is an error parsing the type, pick a new type
for error recovery purposes.

llvm-svn: 40029

llvm-svn: 40027

a function-like macro invocation.  Patch contributed by Neil Booth.

llvm-svn: 40026

llvm-svn: 40012

This allows us to compile this:

struct abc { char A; double D; };

int foo() {
  return sizeof(struct abc);
  return __alignof__(struct abc);
}

Into:

        ret i32 16
        ret i32 8

llvm-svn: 40010

llvm-svn: 40009

First round of extended vector support. Here is an overview...

- added ocu_vector_type attribute, Sema::HandleOCUVectorTypeAttribute(). 
- added new AST node, OCUVectorType, a subclass of VectorType.
- added ASTContext::getOCUVectorType.
- changed ASTContext::convertToVectorType() to ASTContext::getVectorType(). This is 
unrelated to extended vectors, however I was in the vicinity and it was on my todo list.
Added a FIXME to Sema::HandleVectorTypeAttribute to deal with converting complex types.

llvm-svn: 40007

hooked up to anything, so it's not very useful yet.

llvm-svn: 40006

llvm-svn: 40005

llvm-svn: 40003

llvm-svn: 39996

llvm-svn: 39994

llvm-svn: 39989

just always use strtod.  This is temporary code anyway.

llvm-svn: 39972

llvm-svn: 39970

llvm-svn: 39960

llvm-svn: 39958

llvm-svn: 39956

Change dyn_cast for reference types to be more like pointers and not need the canonical type. Also fix so that we're not expecting a return value from a void function

llvm-svn: 39954

    According to the spec (C++ 5p6[expr]), we need to adjust "T&" to
    "T" before further analysis. We do this via the "implicit cast"
    thingy.

llvm-svn: 39953

Convert UsualArithmeticConversions to return "void". Now that we synthesize ImplicitCastExpr's,
there is no compelling need to return the converted type. If both expression type's are arithmetic, then
both types will always be the same. If they aren't (for pointer/int types, say), then the
types will be different. The client is responsible for distinguishing...

llvm-svn: 39947

Implement semantic analysis for the cast operator.

llvm-svn: 39943

Remove the 2 QualType references to method UsualArithmeticConversions. Last week, I added these
to quickly fix a regression. Avoiding them entirely is a much cleaner solution. Clients of 
UsualArithmeticConversions should simply call getType() on the expression to get the
converted type. In practice, only a small number of routines care about this.

llvm-svn: 39934

isPointerType and isVectorType to only look through a single level of typedef
when one is present.  For this invalid code:

typedef float float4 __attribute__((vector_size(16)));
typedef int int4 __attribute__((vector_size(16)));
typedef int4* int4p;
void test(float4 a, int4p result, int i) {
    result[i] = a;
}

we now get:

t.c:5:15: error: incompatible types assigning 'float4' to 'int4'
    result[i] = a;
    ~~~~~~~~~ ^ ~

instead of:

t.c:5:15: error: incompatible types assigning 'float4' to 'int  __attribute__((vector_size(16)))'
    result[i] = a;
    ~~~~~~~~~ ^ ~

The rest of the type predicates should be upgraded to do the same thing.

llvm-svn: 39932

Change DefaultFunctionArrayConversions and UsualUnaryConversions to return void. The caller 
needs to query the expression for the type. Since both these functions guarantee the expression 
contains a valid type, removed old/vacuous asserts (from code calling both of these routines).

llvm-svn: 39930

SemaExpr.cpp:561: warning: dereferencing type-punned pointer will break strict-aliasing rules

Patch by Benoit Boissinot!

llvm-svn: 39928

llvm-svn: 39927

llvm-svn: 39925

llvm-svn: 39907

accurate diagnostics.  For test/Lexer/comments.c we now emit:

int x = 000000080;  /* expected-error {{invalid digit}} */
               ^
constants.c:7:4: error: invalid digit '8' in octal constant
00080;             /* expected-error {{invalid digit}} */
   ^


The last line is due to an escaped newline.  The full line looks like:

int y = 0000\
00080;             /* expected-error {{invalid digit}} */


Previously, we emitted:
constants.c:4:9: error: invalid digit '8' in octal constant
int x = 000000080;  /* expected-error {{invalid digit}} */
        ^
constants.c:6:9: error: invalid digit '8' in octal constant
int y = 0000\
        ^

which isn't too bad, but the new way is better for the user,
regardless of whether there is an escaped newline or not.

All the other lexer-related diagnostics should switch over 
to using AdvanceToTokenCharacter where appropriate.  Help
wanted :).

This implements test/Lexer/constants.c.

llvm-svn: 39906

specifying the start of a token and a logical (phase 3) character number,
returns a sloc representing the input character corresponding to it.

llvm-svn: 39905

llvm-svn: 39904