- Allows definitions of overloaded functions :)
- Eliminates extraneous error messages when we have a definition of a
function that isn't an overload but doesn't have exactly the same type
as the original.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@58382 91177308-0d34-0410-b5e6-96231b3b80d8
ImplicitConversionSequence and, when doing so, following the specific
rules of [over.best.ics].
The computation of the implicit conversion sequences implements C++
[over.ics.ref], but we do not (yet) have ranking for implicit
conversion sequences that use reference binding.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@58357 91177308-0d34-0410-b5e6-96231b3b80d8
of copy initialization. Other pieces of the puzzle:
- Try/Perform-ImplicitConversion now handles implicit conversions
that don't involve references.
- Try/Perform-CopyInitialization uses
CheckSingleAssignmentConstraints for C. PerformCopyInitialization
is now used for all argument passing and returning values from a
function.
- Diagnose errors with declaring references and const values without
an initializer. (Uses a new Action callback, ActOnUninitializedDecl).
We do not yet have implicit conversion sequences for reference
binding, which means that we don't have any overloading support for
reference parameters yet.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@58353 91177308-0d34-0410-b5e6-96231b3b80d8
- CastExpr is the root of all casts
- ImplicitCastExpr is (still) used for all explicit casts
- ExplicitCastExpr is now the root of all *explicit* casts
- ExplicitCCastExpr (new name needed!?) is a C-style cast in C or C++
- CXXFunctionalCastExpr inherits from ExplicitCastExpr
- CXXNamedCastExpr inherits from ExplicitCastExpr and is the root of all
of the C++ named cast expression types (static_cast, dynamic_cast, etc.)
- Added classes CXXStaticCastExpr, CXXDynamicCastExpr,
CXXReinterpretCastExpr, and CXXConstCastExpr to
Also, fixed returned-stack-addr.cpp, which broke once when we fixed
reinterpret_cast to diagnose double->int* conversions and again when
we eliminated implicit conversions to reference types. The fix is in
both testcase and SemaChecking.cpp.
Most of this patch is simply support for the renaming. There's very
little actual change in semantics.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@58264 91177308-0d34-0410-b5e6-96231b3b80d8
There is still a bug here (as the FIXME in the test case indicates). Prior to this patch, the bug would generate an error. Now, we simply do nothing (which is less harmful until we can get it right). The complete bug fix will require changing ASTContext::mergeTypes(), which I'd like to defer for now.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@58241 91177308-0d34-0410-b5e6-96231b3b80d8
struct foo Y[10] = {
[4] .arr [2] 4 // expected-error {{expected '=' or another designator}}
};
because the "missing equals" extension only is valid if there
is exactly one array designator.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@58215 91177308-0d34-0410-b5e6-96231b3b80d8
-Add withConst/withVolatile/withRestrict methods to QualType class, that return the QualType plus the respective qualifier.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@58120 91177308-0d34-0410-b5e6-96231b3b80d8
Enhance test to include a case where a tracked object escapes because it is stored to a local ivar through a method dispatch to 'self.'
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@58109 91177308-0d34-0410-b5e6-96231b3b80d8
conversions.
Added PerformImplicitConversion, which follows an implicit conversion sequence
computed by TryCopyInitialization and actually performs the implicit
conversions, including the extra check for ambiguity mentioned above.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@58071 91177308-0d34-0410-b5e6-96231b3b80d8
pointer-to-base. Also, add overload ranking for pointer conversions
(for both pointer-to-void and derived-to-base pointer conversions).
Note that we do not yet diagnose derived-to-base pointer conversion
errors that stem from ambiguous or inacessible base classes. These
aren't handled during overload resolution; rather, when the conversion
is actually used we go ahead and diagnose the error.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@58017 91177308-0d34-0410-b5e6-96231b3b80d8
Mea culpa: I introduced this regresson in the following 2 commits: r57529 (10/14), r57841 (10/20).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@58007 91177308-0d34-0410-b5e6-96231b3b80d8
Teach Sema::ActOnMemberReferenceExpr() to look through local category implementations associated with the class.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@57995 91177308-0d34-0410-b5e6-96231b3b80d8
don't have duplicated direct base classes.
Seriliazation of base class specifiers is not yet implemented.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@57991 91177308-0d34-0410-b5e6-96231b3b80d8
conversions (e.g., comparing int* -> const int* against
int* -> const volatile int*); see C++ 13.3.3.2p3 bullet 3.
Add Sema::UnwrapSimilarPointerTypes to simplify the control flow of
IsQualificationConversion and CompareQualificationConversion (and fix
the handling of the int* -> volatile int* conversion in the former).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@57978 91177308-0d34-0410-b5e6-96231b3b80d8
Changes:
- Sema::IsQualificationConversion determines whether we have a qualification
conversion.
- Sema::CheckSingleAssignment constraints now follows the C++ rules in C++,
performing an implicit conversion from the right-hand side to the type of
the left-hand side rather than checking based on the C notion of
"compatibility". We now rely on the implicit-conversion code to
determine whether the conversion can happen or
not. Sema::TryCopyInitialization has an ugly reference-related
hack to cope with the initialization of references, for now.
- When building DeclRefExprs, strip away the reference type, since
there are no expressions whose type is a reference. We'll need to
do this throughout Sema.
- Expr::isLvalue now permits functions to be lvalues in C++ (but not
in C).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@57935 91177308-0d34-0410-b5e6-96231b3b80d8
Fix <rdar://problem/6265257> warnings for ambiguous message send swamp other warnings.
Reworked Sema::MatchTwoMethodDeclarations() to optionally match based on method size and alignment (the default in GCC). Changed Sema::LookupInstanceMethodInGlobalPool() to use this feature.
Added -Wno-struct-selector-match to driver, however didn't hook it up yet. Added a FIXME that says this.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@57898 91177308-0d34-0410-b5e6-96231b3b80d8
crash.m:8:12: error: type name requires a specifier or qualifier
@property (readonlyx, getter=isAwesome) int _awesome;
^
crash.m:8:29: error: expected ';' at end of declaration list
@property (readonlyx, getter=isAwesome) int _awesome;
^
crash.m:8:39: error: expected identifier or '('
@property (readonlyx, getter=isAwesome) int _awesome;
^
we now get:
crash.m:8:12: error: unknown property attribute 'readonlyx'
@property (readonlyx, getter=isAwesome) int _awesome;
^
Also, we can eliminate isObjCPropertyAttribute now.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@57811 91177308-0d34-0410-b5e6-96231b3b80d8
Check for @end in ParseObjCInterfaceDeclList instead of in each caller
Handle @required and @optional with the same code
Add some fixmes about some apparently objc2 code that is being accepted
in objc1.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@57803 91177308-0d34-0410-b5e6-96231b3b80d8
of whether a '(' was a grouping paren or the start of a function declarator.
This is PR2796.
Now we eat the attribute before deciding whether the paren is grouping or
not, then apply it to the resultant decl or to the first argument as needed.
One somewhat surprising aspect of this is that attributes interact with
implicit int in cases like this:
void a(x, y) // k&r style function
void b(__attribute__(()) x, y); // function with two implicit int arguments
void c(x, __attribute__(()) y); // error, can't have attr in identifier list.
Fun stuff.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@57790 91177308-0d34-0410-b5e6-96231b3b80d8
- Support noreturn on function-typed variables.
- Extend isFunctionOrMethod to return true for K&R functions and
provide hasFunctionProto to check if a decl has information about
its arguments. This code needs some serious cleaning, but works.
- Add/improve test cases for noreturn and unused.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@57778 91177308-0d34-0410-b5e6-96231b3b80d8
structure.
- I'm not sure yet about the behavior, but this at least prevents the
crash.
Add some asserts on RegionStack usage.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@57661 91177308-0d34-0410-b5e6-96231b3b80d8
floats.
- With testcase, which also has some other things GCC folds but we
don't commented out in it.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@57624 91177308-0d34-0410-b5e6-96231b3b80d8
is to encode the state of the #pragma pack stack as an attribute when
the structure is declared.
- Extend PackedAttr to take an alignment (in bits), and reuse for
both __attribute__((packed)) (which takes no argument, instead
packing tightly (to "minimize the memory required") and for #pragma
pack (which allows specification of the maximum alignment in
bytes). __attribute__((packed)) is just encoded as Alignment=1.
This conflates two related but different mechanisms, but it didn't
seem worth another attribute.
- I have attempted to follow the MSVC semantics as opposed to the gcc
ones, since if I understand correctly #pragma pack originated with
MSVC. The semantics are generally equivalent except when the stack
is altered during the definition of a structure; its not clear if
anyone does this in practice. See testcase if curious.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@57623 91177308-0d34-0410-b5e6-96231b3b80d8
typedef int f();
struct S {
f *x; // incorrectly assuming this is function decl, leading to failed assertions.
};
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@57598 91177308-0d34-0410-b5e6-96231b3b80d8
Note: One day, we should consider moving the actual diags to ObjCQualifiedIdTypesAreCompatible(), since it has more information on the actual problem. GCC currently emits slightly more instructive errors for some cases involving protocols. I added a FIXME to the code.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@57529 91177308-0d34-0410-b5e6-96231b3b80d8
- Follows the MSVC (original) implementation, including support of
pack(show) (useful for testing).
- Implements support for named pack records which gcc seems to
ignore (or implements incorrectly).
- Not currently wired to anything, only functionality change is the
type checking of the pragma.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@57476 91177308-0d34-0410-b5e6-96231b3b80d8
class C {
static const int number = 50;
static int arr[number];
};
Here's how it worked:
-GetTypeForDeclarator was called from both Sema::ActOnCXXMemberDeclarator and Sema::ActOnDeclarator.
-VariableArrayTypes are not uniqued so two VariableArrayTypes were created with the same DeclRefExpr.
-On exit they both tried to destroy that one DeclRefExpr.
The fix is not to use GetTypeForDeclarator from the Sema::ActOnCXXMemberDeclarator.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@57313 91177308-0d34-0410-b5e6-96231b3b80d8
Fixes this bug:
int (x)(0); // error, expected function declarator where the '(0)' initializer is
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@57241 91177308-0d34-0410-b5e6-96231b3b80d8
This is how this kind of initializers appear in the AST:
-The Init expression of the VarDecl is a functional type construction (of the VarDecl's type).
-The new VarDecl::hasCXXDirectInitializer() returns true.
e.g, for "int x(1);":
-VarDecl 'x' has Init with expression "int(1)" (CXXFunctionalCastExpr).
-hasCXXDirectInitializer() of VarDecl 'x' returns true.
A major benefit is that clients that don't particularly care about which exactly form was the initializer can handle both cases without special case code.
Note that codegening works now for "int x(1);" without any changes to CodeGen.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@57178 91177308-0d34-0410-b5e6-96231b3b80d8
constant lvalue. Implement this in codegen by moving the code out of CGBuiltin
into EmitConstantExpr.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@57163 91177308-0d34-0410-b5e6-96231b3b80d8
condition as a constant even if the unevaluated side is a not a constant.
We don't do this when extensions are off, and we emit a warning when this
happens:
t.c:22:11: warning: expression is not a constant, but is accepted as one by GNU extensions
short t = __builtin_constant_p(5353) ? 42 : somefunc();
^ ~~~~~~~~~~
suggestions for improvement are welcome. This is obviously horrible, but
is required for real-world code.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@57153 91177308-0d34-0410-b5e6-96231b3b80d8
This was the motivation of the following changes:
-'TentativeParsingResult' enum is replaced by a 'TPResult' class that basically encapsulates the enum.
-TPR_true, TPR_false, TPR_ambiguous, and TPR_error enum constants are replaced by TPResult::True(), TPResult::False(), etc. calls that return a TPResult object.
-Also fixed the subtle bug in Parser::isCXXFunctionDeclarator (caught by the above changes as a compilation error).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@57125 91177308-0d34-0410-b5e6-96231b3b80d8
'ParseTentative.cpp' implements the functionality needed to resolve ambiguous C++ statements, to either a declaration or an expression, by "tentatively parsing" them.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@57084 91177308-0d34-0410-b5e6-96231b3b80d8
- AST printing, dumping, serialization, codegen.
- HTML printing.
- Parser callbacks.
Several of these are XFAIL because they trigger unimplemented code.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@57081 91177308-0d34-0410-b5e6-96231b3b80d8
- env-include-paths.c is XFAIL as it exposed a bug.
Add test/Coverage.
- For tests which achieve code coverage but don't validate anything.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@57070 91177308-0d34-0410-b5e6-96231b3b80d8
- Enabled for builtins which are always constant expressions
(__builtin_huge_val*, __builtin_inf*, __builtin_constant_p,
__builtin_classify_type, __builtin___CFStringMakeConstantString).
Added Builtin::Context::isConstantExpr.
- Currently overly simply interface which only works for builtins
whose constantexprness does not depend on their arguments.
CallExpr::isBuiltinConstantExpr now takes an ASTContext argument.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@56983 91177308-0d34-0410-b5e6-96231b3b80d8
Long standing bug in Sema::ActOnInstanceMessage(). We now warn when messaging an "id" with multiple method signatures in scope. The diags are a little verbose, however they can be streamlined if necessary.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@56843 91177308-0d34-0410-b5e6-96231b3b80d8
fixes problems handling references of va_list, which happens on x86_64.
This fixes PR2841 and rdar://6252231
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@56809 91177308-0d34-0410-b5e6-96231b3b80d8
by decaying __builtin_va_list's type when forming builtins. On
x86-64 (and other targets) __builtin_va_list is a typedef for
an array.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@56768 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes <rdar://problem/6248392> clang: Error when using address of stack variable inside block.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@56652 91177308-0d34-0410-b5e6-96231b3b80d8
- readonly and readwrite are mutually exclusive.
- assign, copy, and retain are mutually exclusive.
- copy and retain are invalid on non-object types.
- Warn about using default 'assign' property on object types
(attempting to follow gcc behavior).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@56507 91177308-0d34-0410-b5e6-96231b3b80d8
Since we don't have DeclGroup's and location information for types, there is some fancy footwork to do this fairly reliably.
O.K...it's a kludge. One day, we can use this as motivation to do this more gracefully:-)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@56499 91177308-0d34-0410-b5e6-96231b3b80d8
For checking if a symbol >= value, we need to check if symbol == value || symbol
> value. When checking symbol > value and we know that symbol != value, the path
is infeasible only if value == maximum integer.
For checking if a symbol <= value, we need to check if symbol == value || symbol
< value. When checking symbol < value and we know that symbol != value, the path
is infeasible only if value == minimum integer.
Updated test case exercising this logic: we only prune paths if the values are
unsigned.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@56354 91177308-0d34-0410-b5e6-96231b3b80d8
if we know that 'len != 0' and know that 'i == 0' then we know that
'i < len' must evaluate to true and cannot evaluate to false
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@56260 91177308-0d34-0410-b5e6-96231b3b80d8
^(expression) or ^(int arg1, float arg2)(expression)
...is no longer supported.
All block literals now require a compound statement.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@56257 91177308-0d34-0410-b5e6-96231b3b80d8
Sema::CheckReturnStackAddr(): Make sure we skip over implicit casts.
Added some more test cases...
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@56254 91177308-0d34-0410-b5e6-96231b3b80d8
- Follow C99 behavior of using other operand type when one of
operands is a null pointer constant.
- Fix overenthusiastic devolving of any Objective-C types to id:
o If either operand has an Objective-C object type then:
- If both operands are interfaces and either operand can be
assigned to the other, use that type as the composite type.
- Otherwise, if either type is id, use id as the composite type.
- Otherwise, warn about incompatible types and use id as the
composite type.
- Return handling of qualified idea to separate test following
general pointer type checking.
o Upgraded from old code to allow devolving to id (without warning,
which matches GCC).
- <rdar://problem/6212771>
Add test case for issues fixed above, XFAIL though because it exposed
a new issue in property handling.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@56135 91177308-0d34-0410-b5e6-96231b3b80d8
(1) Additional arguments to variadic methods should have default
promotions applied.
(2) Additional arguments to non-variadic methods were allowed.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@56084 91177308-0d34-0410-b5e6-96231b3b80d8
Add new 'ActOnCXXConditionDeclarationExpr' action, called when the 'condition' is a declaration instead of an expression.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@56007 91177308-0d34-0410-b5e6-96231b3b80d8
aliases.
- Attributes specific to a definition are only set when the
definition is seen.
- Alias generation is delayed until the end of the module; necessary
since the alias may reference forward.
- Fixes: PR2743, <rdr://6140807&6094512>
- Improves: <rdr://6095112> (added XFAIL)
Also, print module on verification failures.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@55966 91177308-0d34-0410-b5e6-96231b3b80d8
someone with llvm-gcc installed please test if the Codegen/function-attributes.c test isn't skip in your system. thanks.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@55871 91177308-0d34-0410-b5e6-96231b3b80d8
currently clang passes all tests under valgrind with the leak checker disabled :P (and fails most otherwise)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@55782 91177308-0d34-0410-b5e6-96231b3b80d8
- Note that these don't really test anything other than that code
generation doesn't fail or crash. Better than nothing though!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@55761 91177308-0d34-0410-b5e6-96231b3b80d8
- Allow any Objective-C object types to devolve to type id in a ?:
expression. This matches gcc behavior more closely.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@55705 91177308-0d34-0410-b5e6-96231b3b80d8
- Now also searches for correct setter method.
- There are still some issues regarding validation of the setter
method and access of read-only properties.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@55686 91177308-0d34-0410-b5e6-96231b3b80d8
- Replace FIXME in Preprocessor::HandleIdentifier() with a check that avoids diagnosing extension tokens that originate from macro definitions.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@55639 91177308-0d34-0410-b5e6-96231b3b80d8
Note that this isn't really a complete fix; I think there are other
potential overrun situations. I don't really know what the best
systematic fix is, though.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@55622 91177308-0d34-0410-b5e6-96231b3b80d8
anywhere near correct in terms of missing cases and missing
diagnostics, but it's good enough to handle the uses in the
Linux system headers, which are currently a constant pain for compiling
applications on Linux.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@55621 91177308-0d34-0410-b5e6-96231b3b80d8
type-checking pointer subtraction; if the canonical types aren't used,
the qualifiers won't always get stripped off correctly.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@55620 91177308-0d34-0410-b5e6-96231b3b80d8
- warn about nonnull being applied to functions with no pointer arguments
- continue processing argument list in the attribute when we encounter a non-pointer parameter being marked as nonnull
- when no argument list is specified, only mark pointers as nonnull. This fixes PR 2732 and radar 6188814.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@55610 91177308-0d34-0410-b5e6-96231b3b80d8
Parser support for blocks is almost complete...just need to add support for the __block() storage class qualifier.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@55495 91177308-0d34-0410-b5e6-96231b3b80d8
of RHSs to id type instead of void* if either has Objective-C object
type.
- This ensures the result can still be used in normal places an
object can be used, like a message send.
Add implicit conversions for ?: applied to qualified id types to
ensure that the RHSs are compatible.
- This prevents a codegen crash (creating invalid PHI nodes).
- Again, this relates to the fact that qualified id types have no
canonical types.
- Note that the implicit type casted to is incorrect, however this
doesn't currently cause problems because of the flexibility of the
id type.
Test cases for above.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@55346 91177308-0d34-0410-b5e6-96231b3b80d8
correctly. Not a regression, but made more obvious by my recent fix
which made function type compatibility checking a bit more strict.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@55339 91177308-0d34-0410-b5e6-96231b3b80d8
casting pointers to integers.
Eventually, we should check whether we can evaluate an expression
using Expr::tryEvaluate, and this codepath should be tightened to only
handle standard-compliant cases.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@55331 91177308-0d34-0410-b5e6-96231b3b80d8
make diagnostic output in some other malformed cases significantly
more useful. This fixes PR2708
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@55215 91177308-0d34-0410-b5e6-96231b3b80d8
-The Parser calls a new "ActOnCXXTypeConstructExpr" action.
-Sema, depending on the type and expressions number:
-If the type is a class, it will treat it as a class constructor. [TODO]
-If there's only one expression (i.e. "int(0.5)" ), creates a new "CXXFunctionalCastExpr" Expr node
-If there are no expressions (i.e "int()" ), creates a new "CXXZeroInitValueExpr" Expr node.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@55177 91177308-0d34-0410-b5e6-96231b3b80d8
scripts dir appear before the user path.
- This is an attempt to pick up the right executables. We should
probably be substituting the exact things we want for clang a la
the LLVM test script.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@55105 91177308-0d34-0410-b5e6-96231b3b80d8
directory.
- Removed .ll from the svn:ignore lists to try and prevent this.
- Added svn:ignore on test/Misc/Output
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@55104 91177308-0d34-0410-b5e6-96231b3b80d8