llvm-svn: 41396

This modest change insures ImplicitCastExpr's get generated for all "assignments",
while includes init decls, assignment exprs, call exprs, and return statements.

Here are a few examples with the correct AST's...

[dylan:~/llvm/tools/clang] admin% cat impcomp.c

_Complex double X;
void test2(int c) {
  X = 5;
}
void foo() {
  int i;
  double d = i;
  double _Complex a = 5;

  test2(a);
  a = 5;
  d = i;
}


[dylan:~/llvm/tools/clang] admin% ../../Debug/bin/clang impcomp.c -parse-ast-dump
Read top-level variable decl: 'X'

void test2(int c)
(CompoundStmt 0x2605ce0
  (BinaryOperator 0x2605cc0 '_Complex double' '='
    (DeclRefExpr 0x2605c70 '_Complex double' Decl='X' 0x2605af0)
    (ImplicitCastExpr 0x2605cb0 '_Complex double'
      (IntegerLiteral 0x2605c90 'int' 5))))


void foo()
(CompoundStmt 0x2606030
  (DeclStmt 0x2605bd0
    0x2605d90 "int i")
  (DeclStmt 0x2605e20
    0x2605de0 "double d =
      (ImplicitCastExpr 0x2605e10 'double'
        (DeclRefExpr 0x2605dc0 'int' Decl='i' 0x2605d90))")
  (DeclStmt 0x2605e90
    0x2605e50 "_Complex double a =
      (ImplicitCastExpr 0x2605e80 '_Complex double'
        (IntegerLiteral 0x2605e30 'int' 5))")
  (CallExpr 0x2605f20 'void'
    (ImplicitCastExpr 0x2605f00 'void (*)(int)'
      (DeclRefExpr 0x2605ea0 'void (int)' Decl='test2' 0x2605c00))
    (ImplicitCastExpr 0x2605f10 'int'
      (DeclRefExpr 0x2605ec0 '_Complex double' Decl='a' 0x2605e50)))
  (BinaryOperator 0x2605fa0 '_Complex double' '='
    (DeclRefExpr 0x2605f50 '_Complex double' Decl='a' 0x2605e50)
    (ImplicitCastExpr 0x2605f90 '_Complex double'
      (IntegerLiteral 0x2605f70 'int' 5)))
  (BinaryOperator 0x2606010 'double' '='
    (DeclRefExpr 0x2605fc0 'double' Decl='d' 0x2605de0)
    (ImplicitCastExpr 0x2606000 'double'
      (DeclRefExpr 0x2605fe0 'int' Decl='i' 0x2605d90))))

llvm-svn: 41379

llvm-svn: 41377

llvm-svn: 41375

Surpress ImplicitCastExprs for compound assignment expressions. For compound assignments,
it is o.k. for the LHS and RHS to have different types. Converting the type can cause
errors like the one Chris noticed (below).

This change required a fair number of diffs (since there is a lot of shared code
between single and compound assignments). This makes the API's look a bit uglier,
however I couldn't think of a better way to do it (without duplicating code).

Fix the following (incorrect) error:

int A;
long long B;

void foo() {
  A /= B;
}

$ clang ~/scalar.c -emit-llvm
/Users/sabre/scalar.c:6:5: error: expression is not assignable
  A /= B;
  ~ ^

Now it works properly...

[dylan:~/llvm/tools/clang] admin% cat compound.c
int A;
long long B;

void foo() {
  A /= B;
}
[dylan:~/llvm/tools/clang] admin% ../../Debug/bin/clang compound.c -parse-ast-dump
Read top-level variable decl: 'A'
Read top-level variable decl: 'B'

void foo()
(CompoundStmt 0x2605c40
  (BinaryOperator 0x2605c20 'int' '/=' ComputeTy='long long'
    (DeclRefExpr 0x2605be0 'int' Decl='A' 0x2605a80)
    (DeclRefExpr 0x2605c00 'long long' Decl='B' 0x2605ab0)))

llvm-svn: 41364

Make sure we get extension diagnostics for GCC's complex extensions.

Now we emit the following when -pedantic-errors is enabled...

[dylan:~/llvm/tools/clang] admin% ../../Debug/bin/clang complex.c -pedantic-errors
complex.c:4:3: error: ISO C does not support '++'/'--' on complex integer types
  ++x;
  ^ ~
complex.c:9:7: error: ISO C does not support '~' for complex conjugation
  X = ~Y;
      ^
complex.c:10:7: error: ISO C does not support '~' for complex conjugation
  x = ~y;
      ^

llvm-svn: 41362

fixes an assertion on:
void f (int z) { switch (z) { case ~0ULL: case -1: return; } }

testcase from Neil.

llvm-svn: 41343

Support '~' for complex conjugation. This is a GCC extension.

This following now compiles without error...

_Complex unsigned X, Y;
_Complex double x, y;
void test2(int c) {
  X = ~Y;
  x = ~y;
}

llvm-svn: 41341

llvm-svn: 41340

Now, the following test case succeeds...

_Complex double x, y;
void test2(int c) {
  ++x;
}

llvm-svn: 41335

verifying case ranges.

llvm-svn: 41331

switch.c:16:8: warning: empty case range specified
  case 100 ... 99: ;  // expected-warning {{empty case range}}
       ^~~~~~~~~~

llvm-svn: 41328

llvm-svn: 41317

llvm-svn: 41315

warnings when converting case values to the expression type.

llvm-svn: 41313

llvm-svn: 41273

llvm-svn: 41238

llvm-svn: 41232

to getBase and getIdx.  getBase and getIdx now return a "normalized" view
of the expression (e.g., always "A[4]" instead of possibly "4[A]").  getLHS
and getRHS return the expressions with syntactic fidelity to the original
source code.

Also modified client code of ArraySubscriptExpr, including the AST dumper
and pretty printer, the return-stack value checker, and the LLVM code
generator.

llvm-svn: 41180

"return of stack addresses."  ParseReturnStmt now calls CheckReturnStackAddr
to determine if the expression in the return statement evaluates to an
address of a stack variable.  If so, we issue a warning. 

llvm-svn: 41141

llvm-svn: 41140

llvm-svn: 41136

Fixed Sema::CheckEqualityOperands() and Sema::CheckRelationalOperands() to deal more 
thoughtfully with incompatible pointers. This includes:

- Emit a diagnostic when two pointers aren't compatible!
- Promote one of the pointers/integers so we maintain the invariant expected by the 
code generator (i.e. that the left/right types match).
- Upgrade the pointer/integer comparison diagnostic to include the types. 

llvm-svn: 41127

llvm-svn: 41079

family of functions.  Previous functionality only included checking to
see if the format string was a string literal.  Now we check parse the
format string (if it is a literal) and perform the following checks:

(1) Warn if: number conversions (e.g. "%d") != number data arguments.

(2) Warn about missing format strings  (e.g., "printf()").

(3) Warn if the format string is not a string literal.

(4) Warn about the use se of '%n' conversion.  This conversion is
    discouraged for security reasons.

(5) Warn about malformed conversions.  For example '%;', '%v'; these
    are not valid.

(6) Warn about empty format strings; e.g. printf("").  Although these
    can be optimized away by the compiler, they can be indicative of
    broken programmer logic.  We may need to add additional support to
    see when such cases occur within macro expansion to avoid false
    positives.

(7) Warn if the string literal is wide; e.g. L"%d".

(8) Warn if we detect a '\0' character WITHIN the format string.

Test cases are included.

llvm-svn: 41076

by CheckPrintfArguments to determine if a given printf function
accepts a va_arg argument.

llvm-svn: 41008

KnownFunctionIDs.  This allows us to test for a printf-like function
that accepts a va_arg argument using a range comparison.

llvm-svn: 41006

"I've coded up some support in clang to flag warnings for non-constant format strings used in calls to printf-like functions (all the functions listed in "man fprintf").  Non-constant format strings are a source of many security exploits in C/C++ programs, and I believe are currently detected by gcc using the flag -Wformat-nonliteral."

llvm-svn: 41003

Make sure the arithmetic conversion are done for relation and equality operators.

This fixes the following...

eypedef short S;
int test(S X, long long Y) {
  return X < Y;
}

Before...

(CompoundStmt 0x2905d00
  (ReturnStmt 0x2905cf0
    (BinaryOperator 0x2905cd0 'int' '<'
      (ImplicitCastExpr 0x2905cc0 'int'
        (DeclRefExpr 0x2905c80 'S':'short' Decl='X' 0x2905c20))
      (DeclRefExpr 0x2905ca0 'long long' Decl='Y' 0x2905c50))))

After...

(CompoundStmt 0x2b05c30
  (ReturnStmt 0x2b05c20
    (BinaryOperator 0x2b05c00 'int' '<'
      (ImplicitCastExpr 0x2b05bf0 'long long'
        (DeclRefExpr 0x2b05bb0 'S':'short' Decl='X' 0x2b05b50))
      (DeclRefExpr 0x2b05bd0 'long long' Decl='Y' 0x2b05b80))))

llvm-svn: 40999

Move the function/array conversion for ParmVarDecl's from Sema::ParseIdentifierExpr()
to Sema::ParseParamDeclarator(). After discussing this with Chris, we decided this
approach has more immediate benefit (though we loose some information in the AST). 
The comment below should describe more (if interested).

llvm-svn: 40907

Remove a space from "typeof" printing. It was causing the following error...

[dylan:clang/test/Parser] admin% ../../../../Debug/bin/clang -parse-ast-check typeof.c 
Warnings expected but not seen:
  Line 21: incompatible types assigning 'typeof(*pi) const' to 'int *'
Warnings seen but not expected:
  Line 21: incompatible types assigning 'typeof(*pi)  const' to 'int *'

Also corrected a typo from my previous commit.

llvm-svn: 40832

Make sure the good old "function/array conversion" is done to function parameters.

This resulted in the following error...

[dylan:clang/test/Parser] admin% cat parmvardecl_conversion.c 
// RUN: clang -parse-ast-check %s

void f (int p[]) { p++; }

[dylan:clang/test/Parser] admin% clang -parse-ast-check parmvardecl_conversion.c 
Errors seen but not expected:
  Line 3: cannot modify value of type 'int []'

With this fix, the test case above succeeds.

llvm-svn: 40831

Chris suggested this, since it simplifies the code generator.
If this features is needed (and we don't think it is), we can revisit.

The following test case now produces an error.
[dylan:~/llvm/tools/clang] admin% cat t.c

typedef __attribute__(( ocu_vector_type(4) )) float float4;

static void test() {
    float4 vec4;

    vec4.rg.g;
    vec4.rg[1];
}
[dylan:~/llvm/tools/clang] admin% ../../Debug/bin/clang t.c
t.c:8:12: error: vector component access limited to variables
    vec4.rg.g;
           ^~
t.c:9:12: error: vector component access limited to variables
    vec4.rg[1];
           ^~~
2 diagnostics generated.

llvm-svn: 40795

Implement __builtin_choose_expr.

llvm-svn: 40794

Rename AddrLabel and OCUVectorComponent -> AddrLabelExpr and OCUVectorElementExpr respectively.  This is for consistency with other expr nodes end with *Expr.

llvm-svn: 40785

llvm-svn: 40764

- Finish hooking up support for __builtin_types_compatible_p().
- Fix type printing code for recently added TypeOfExpr/TypeOfType.

llvm-svn: 40700

Add AST/Sema support for __builtin_types_compatible_p (a GNU extension).
Todo...still need to call the action from the parser...

llvm-svn: 40693

Two typeof() related changes...

- Changed the name of ASTContext::getTypeOfType(Expr*)->getTypeOfExpr().
- Remove FIXME for TypeOfExpr::getAsStringInternal(). This will work fine for printing the AST. It isn't ideal
for error diagnostics (since it's more natural to display the expressions type). 

One "random" (or at least delayed:-) change...

- Changed all "ext_typecheck_*" diagnostics from EXTENSION->WARNING. Reason: Since -pedantic is now
off (by default), these diagnostics were never being emitted (which is bad). With this change, clang will
emit the warning all the time. The only downside (wrt GCC compatibility) is -pedantic-errors will not turn
this diagnostics into errors (a "feature" of making tagging them with EXTENSION). When/if this becomes
an issue, we can revisit.

llvm-svn: 40676

llvm-svn: 40653