llvm-svn: 39617

- Say! why don't we increment the NumDiagnostics variable too?

llvm-svn: 39616

Reviewed by: Chris Lattner

- Make the counting of errors and diagnostic messages sane. Place them into the
  Diagnostic class instead of in the DiagnosticClient class.

llvm-svn: 39615

llvm-svn: 39614

llvm-svn: 39613

llvm-svn: 39612

corresponding file buffer, don't dereference null pointers.  This
fixes a regression on test/Preprocessor/_Pragma-syshdr.c

llvm-svn: 39611

llvm-svn: 39610

llvm-svn: 39609

llvm-svn: 39608

but where we didn't warn about __attribute__.

llvm-svn: 39607

llvm-svn: 39606

diag.c:1:9: error: invalid digit '8' in octal constant
int x = 000080;
        ^
diag.c:2:9: error: invalid digit 'A' in decimal constant
int z = 1000080ABC;
        ^

instead of:

diag.c:1:9: error: invalid suffix '80' on integer constant
int x = 000080;
        ^
diag.c:2:9: error: invalid suffix 'ABC' on integer constant
int z = 1000080ABC;
        ^

llvm-svn: 39605

- Renamed file guard.

llvm-svn: 39604

Reviewed by: Chris Lattner

- Separated out the diagnostic client from the clang driver. This is in
  preparation for creating a diagnostic client that will be used to check
  error and warning messages.

llvm-svn: 39603

Submitted by:
Reviewed by:

Fixed a bug in the parser's handling of attributes on pointer declarators.

For example, the following code was producing a syntax error...

int *__attribute(()) foo;

attrib.c:10:25: error: expected identifier or '('
int *__attribute(()) foo;
                        ^
Changed Parser::ParseTypeQualifierListOpt to not consume the token following
an attribute declaration.

Also added LexerToken::getName() convenience method...useful when tracking
down errors like this.

llvm-svn: 39602

Submitted by:
Reviewed by:

The following code illustrates a bug in the semantic analysis for assignments:

int func() {
  int *P;
  char *x;
  P = x; // type of this assignment expression should be "int *", NOT "char *".
}

While the type checking/diagnostics are correct, the type of the assignment
expression is incorrect (which shows up during code gen).  With the fix,
the llvm code looks correct...

[dylan:~/llvm/tools/clang] admin% ../../Debug/bin/clang cast.c -emit-llvm
cast.c:4:5: warning: incompatible pointer types assigning 'char *' to 'int *'
  P = x; // type of assignment expression is "int *", NOT "char *".
  ~ ^ ~
; ModuleID = 'foo'

define i32 @func() {
entry:
        %P = alloca i32*                ; <i32**> [#uses=1]
        %x = alloca i8*         ; <i8**> [#uses=1]
        %allocapt = bitcast i32 undef to i32            ; <i32> [#uses=0]
        %tmp = load i8** %x             ; <i8*> [#uses=1]
        %conv = bitcast i8* %tmp to i32*                ; <i32*> [#uses=1]
        store i32* %conv, i32** %P
        ret i32 undef
}

Even though the fix was simple, I decided to rename/refactor the surrounding code
to make a clearer distinction between constraint checking and conversion.

- Renamed AssignmentConversionResult -> AssignmentCheckResult.
- Renamed UsualAssignmentConversions -> CheckAssignmentConstraints.
- Changed the return type of CheckAssignmentConstraints and CheckPointerTypesForAssignment
from QualType -> AssignmentCheckResult. These routines no longer take a reference to the result (obviously).
- Changed CheckAssignmentOperands to return the correct type (with spec annotations).

llvm-svn: 39601

after the expr along with the expr.  If we don't do this, the semicolon
gets parsed as a nullstmt, which makes the generated AST very strange.

llvm-svn: 39600

  int *P2;
  P2(1, 2, 3);

  register short X;
  X();

emit:

ds.c:10:3: error: called object is not a function or function pointer
  P2(1, 2, 3);
  ^~~~~~~~~~~
ds.c:13:3: error: called object is not a function or function pointer
  X();
  ^~~

instead of aborting.

llvm-svn: 39599

int func() {
 int (*FP)();
 FP();
 (*****FP)();
}

llvm-svn: 39598

llvm-svn: 39597

llvm-svn: 39596

llvm-svn: 39595

llvm-svn: 39594

llvm-svn: 39593

llvm-svn: 39592

llvm-svn: 39591

llvm-svn: 39590

Submitted by:
Reviewed by:
Touch up a couple comments (one was incorrect/out-of-date).

llvm-svn: 39589

llvm-svn: 39588

check canonical types in a few places.  Tighten up VerifyConstantArrayType
to diagnose more errors, now that we can evaluate i-c-e's.  Add some fixmes
about poor diagnostics.

We now correctly typecheck this example:

void s(void) {
  typedef int a[(int) +1.0];
  static a b;    // invalid, static VLA

  static int c[(int) +1.0];  // invalid, static VLA
}

void t(void) {
  typedef int a[(int)1.0];
  static a b;    // valid, constant size
}

void u() {
  static int X[-1];
  static int Y[0];
}

producing:

static-vla.c:3:12: error: variable length array declared outside of any function
  static a b;    // invalid, static VLA
           ^
static-vla.c:5:14: error: variable length array declared outside of any function
  static int c[(int) +1.0];  // invalid, static VLA
             ^ ~~~~~~~~~~
static-vla.c:15:14: error: array size is negative
  static int X[-1];
             ^ ~~
static-vla.c:16:14: warning: zero size arrays are an extension
  static int Y[0];
             ^ ~

llvm-svn: 39587

on complete types.

llvm-svn: 39586

  1. Compute and return the value of the i-c-e if the expression is one.
  2. Use this computation to correctly track whether subexprs are being
     evaluated, and use this to guide diagnostics appropriately.

This allows us to correctly handle all the cases in:

void bar() {
  int foo();
  switch (1) {
  case 1 ? 0 : foo():    // bad
  case 0 ? 0 : foo():    // bad

  case 0 ? 1/0 : 14 :  // ok
  case 1 ? 1/0 : 14 :  // bad
    ;
  }

  switch (1) {
  case 1 ? 2: (2, 3): // ok
  case 0 ? 2: (2, 3): // invalid comma.
    ;
  }
}

This code has numerous todo items.  Specifically, we need to:
  1. Pass in target info, so we know the size of the integers we are producing.
  2. Model type sizes and alignments correctly, so we can eval sizeof/alignof
  3. Handle promotions (need to talk to steve about this).
  4. Return an enum that can be used to better diagnose problems with i-c-e's.
     instead of just saying "this isn't valid" we should be able to say why.
  5. Various other miscellanea, like handling enums and character literals
     properly.

llvm-svn: 39585

isConstantExpr into just isIntegerConstantExpr in preparation for other
changes.

llvm-svn: 39584

llvm-svn: 39583

llvm-svn: 39582

Submitted by:
Reviewed by:
Fixed an "impurity" in the typechecking code (to more closely model the
C99 spec)...

- Added function Sema::DefaultFunctionArrayConversion(). This is called
by UsualUnaryConversions(). It is also called from several contexts that
don't call for integer promotions (logical negation for expressions, and
while/if/do/for conditions in statements). It is also used in
UsualAssignmentConversions (which is cleaner than the check I was using
before).

- Changed the name from UsualUnaryConversion->UsualUnaryConversions.

- Added comments to the header.

Since several contexts don't call for integer
promotions,

llvm-svn: 39581

Submitted by:
Reviewed by:
Apply UsualUnaryConversion() to statement conditions that expect scalars.
UsualUnaryConversion() converts function/arrays to pointers.

This fixes the following...

int func() {
  int A[10];
  while (A) {
  }
  if (A) ;
  for (; A; ) ;
}

llvm-svn: 39580

llvm-svn: 39579

llvm-svn: 39578