| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
| |
glaring logic bug anyways. =D
llvm-svn: 95533
|
| |
|
|
|
|
|
|
|
|
| |
deduction. This requires refactoring the deduction to have access to the Sema
object instead of merely the ASTContext. Still leaves something to be desired
due to poor source location.
Fixes PR6257 and half of PR6259.
llvm-svn: 95528
|
| |
|
|
| |
llvm-svn: 95517
|
| |
|
|
| |
llvm-svn: 95510
|
| |
|
|
|
|
| |
Daniel, I'd appreciate a review of the driver/cc1 parts.
llvm-svn: 95508
|
| |
|
|
|
|
|
|
|
|
|
| |
params. Don't insert addrof operations when matching against a pointer;
array/function conversions should take care of this for us, assuming the
argument type-checked in the first place. Add a fixme where we seem to be
using a less-restrictive reference type than we should.
Fixes PR 6249.
llvm-svn: 95495
|
| |
|
|
| |
llvm-svn: 95494
|
| |
|
|
| |
llvm-svn: 95491
|
| |
|
|
| |
llvm-svn: 95487
|
| |
|
|
| |
llvm-svn: 95472
|
| |
|
|
|
|
| |
PR 5517.
llvm-svn: 95470
|
| |
|
|
|
|
|
| |
non-type template argument for a non-type template parameter of
pointer type. Fixes PR6244.
llvm-svn: 95447
|
| |
|
|
|
|
|
|
| |
type-checking within a template definition. In this case, the
"instantiated" declaration is just the declaration itself, found
within the current instantiation. Fixes PR6239.
llvm-svn: 95442
|
| |
|
|
|
|
|
|
|
|
|
|
| |
follows (as conservatively as possible) gcc's current behavior: attributes
written on return types that don't apply there are applied to the function
instead, etc. Only parse CC attributes as type attributes, not as decl attributes;
don't accepet noreturn as a decl attribute on ValueDecls, either (it still
needs to apply to other decls, like blocks). Consistently consume CC/noreturn
information throughout codegen; enforce this by removing their default values
in CodeGenTypes::getFunctionInfo().
llvm-svn: 95436
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
when instantiating the declaration of a member template:
- Only check if the have a template template argument at a specific position
when we already know that we have template arguments at that level;
otherwise, we're substituting for a level-reduced template template
parameter.
- When trying to find an instantiated declaration for a template
template parameter, look into the instantiated scope. This was a
typo, where we had two checks for TemplateTypeParmDecl, one of
which should have been a TemplateTemplateParmDecl.
With these changes, tramp3d-v4 passes -fsyntax-only.
llvm-svn: 95421
|
| |
|
|
|
|
|
|
|
| |
declaration, we can end up with template-id annotation tokens for
types that have not been converted into type annotation tokens. When
this is the case, translate the template-id into a type and parse as
an expression.
llvm-svn: 95404
|
| |
|
|
|
|
| |
Also make the comments I added in r95291 consistent.
llvm-svn: 95394
|
| |
|
|
|
|
|
| |
initializer (for no initialization) rather than a ParenListExpr with
zero arguments in it.
llvm-svn: 95382
|
| |
|
|
|
|
|
| |
always come from the primary template, so gather the instantiation
template arguments from the primary template.
llvm-svn: 95380
|
| |
|
|
|
|
|
|
| |
context. This happens fairly rarely (which is why we got away with
this bug). Fixes PR6184, where we skipped over the template parameter
scope while tentatively parsing.
llvm-svn: 95376
|
| |
|
|
|
|
| |
is a constructor for that class, right? Fixes PR6238.
llvm-svn: 95367
|
| |
|
|
|
|
|
| |
post-increment/post-decrement operators, be sure to consider both
arguments. Fixes PR6237.
llvm-svn: 95361
|
| |
|
|
|
|
| |
dependent DeclContext to be "complete". Fixes PR6236.
llvm-svn: 95359
|
| |
|
|
| |
llvm-svn: 95335
|
| |
|
|
|
|
|
| |
category implementation, which showed up during (attempted) typo
correction. Fixes <rdar://problem/7605289>.
llvm-svn: 95334
|
| |
|
|
|
|
|
|
| |
of a C++ record. Exposed a lot of problems where various routines were
silently doing The Wrong Thing (or The Acceptable Thing in The Wrong Order)
when presented with a non-definition. Also cuts down on memory usage.
llvm-svn: 95330
|
| |
|
|
|
|
| |
analyze_printf namespace.
llvm-svn: 95324
|
| |
|
|
|
|
|
|
|
| |
template parameter, perform array/function decay (if needed), take the
address of the argument (if needed), perform qualification conversions
(if needed), and remove any top-level cv-qualifiers from the resulting
expression. Fixes PR6226.
llvm-svn: 95309
|
| |
|
|
| |
llvm-svn: 95291
|
| |
|
|
|
|
| |
(partial fix for radar 7591784).
llvm-svn: 95245
|
| |
|
|
|
|
| |
working code, for no apparent reason.
llvm-svn: 95244
|
| |
|
|
| |
llvm-svn: 95239
|
| |
|
|
| |
llvm-svn: 95228
|
| |
|
|
|
|
| |
for the reference binding bug that is preventing self-hosting.
llvm-svn: 95223
|
| |
|
|
|
|
|
|
|
|
|
| |
prevent a crash on templates when looking for an existing declaration of the
predefined global operators. This fixes PR5918.
Added an easy test case for the overload handling, but testing the crash is
a bit trickier. Created a new test that can use multiple runs with a define to
trigger which test case is used so we can test this type of issue.
llvm-svn: 95220
|
| |
|
|
|
|
|
| |
reference template arguments. Adds test cases for the cv-quals of reference
arguments.
llvm-svn: 95217
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
that is in an anonymous namespace, give that function or variable
internal linkage.
This change models an oddity of the C++ standard, where names declared
in an anonymous namespace have external linkage but, because anonymous
namespace are really "uniquely-named" namespaces, the names cannot be
referenced from other translation units. That means that they have
external linkage for semantic analysis, but the only sensible
implementation for code generation is to give them internal
linkage. We now model this notion via the UniqueExternalLinkage
linkage type. There are several changes here:
- Extended NamedDecl::getLinkage() to produce UniqueExternalLinkage
when the declaration is in an anonymous namespace.
- Added Type::getLinkage() to determine the linkage of a type, which
is defined as the minimum linkage of the types (when we're dealing
with a compound type that is not a struct/class/union).
- Extended NamedDecl::getLinkage() to consider the linkage of the
template arguments and template parameters of function template
specializations and class template specializations.
- Taught code generation to rely on NamedDecl::getLinkage() when
determining the linkage of variables and functions, also
considering the linkage of the types of those variables and
functions (C++ only). Map UniqueExternalLinkage to internal
linkage, taking out the explicit checks for
isInAnonymousNamespace().
This fixes much of PR5792, which, as discovered by Anders Carlsson, is
actually the reason behind the pass-manager assertion that causes the
majority of clang-on-clang regression test failures. With this fix,
Clang-built-Clang+LLVM passes 88% of its regression tests (up from
67%). The specific numbers are:
LLVM:
Expected Passes : 4006
Expected Failures : 32
Unsupported Tests : 40
Unexpected Failures: 736
Clang:
Expected Passes : 1903
Expected Failures : 14
Unexpected Failures: 75
Overall:
Expected Passes : 5909
Expected Failures : 46
Unsupported Tests : 40
Unexpected Failures: 811
Still to do:
- Improve testing
- Check whether we should allow the presence of types with
InternalLinkage (in addition to UniqueExternalLinkage) given
variables/functions internal linkage in C++, as mentioned in
PR5792.
- Determine how expensive the getLinkage() calls are in practice;
consider caching the result in NamedDecl.
- Assess the feasibility of Chris's idea in comment #1 of PR5792.
llvm-svn: 95216
|
| |
|
|
|
|
| |
initializer. Grrr....
llvm-svn: 95211
|
| |
|
|
|
|
| |
instead allocate the statements after the object.
llvm-svn: 95199
|
| |
|
|
|
|
|
|
| |
realize that CXXConstructExpr is always implicit, so we should just
return its argument (if there is only one) rather than directly
invoking the constructor.
llvm-svn: 95192
|
| |
|
|
| |
llvm-svn: 95190
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Don't use GlobalAliases with non-0 GEPs (GNU runtime) - this was unsupported and LLVM will be generating errors if you do it soon. This also simplifies the code generated by the GNU runtime a bit.
- Make GetSelector() return a constant (GNU runtime), not a load of a store of a constant.
- Recognise @selector() expressions as valid static initialisers (as GCC does).
- Add methods to GCObjCRuntime to emit selectors as constants (needed for using @selector() expressions as constants. These need implementing for the Mac runtimes - I couldn't figure out how to do this, they seem to require a load.
- Store an ObjCMethodDecl in an ObjCSelectorExpr so that we can get at the type information for the selector. This is needed for generating typed selectors from @selector() expressions (as GCC does). Ideally, this information should be stored in the Selector, but that would be an invasive change. We should eventually add checks for common uses of @selector() expressions. Possibly adding an attribute that can be applied to method args providing the types of a selector so, for example, you'd do something like this:
- (id)performSelector: __attribute__((selector_types(id, SEL, id)))(SEL)
withObject: (id)object;
Then, any @selector() expressions passed to the method will be check to ensure that it conforms to this signature. We do this at run time on the GNU runtime already, but it would be nice to do it at compile time on all runtimes.
- Made @selector() expressions emit type info if available and the runtime supports it.
Someone more familiar with the Mac runtime needs to implement the GetConstantSelector() function in CGObjCMac. This currently just assert()s.
llvm-svn: 95189
|
| |
|
|
|
|
| |
suffices.
llvm-svn: 95188
|
| |
|
|
|
|
| |
appropriately. Call out a few missing cases in the expression mangler.
llvm-svn: 95176
|
| |
|
|
|
|
| |
(per Doug's comment).
llvm-svn: 95169
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
lvalue-to-rvalue conversion adjusts lvalues of qualified, non-class
type to rvalue expressions of the unqualified variant of that
type. For example, given:
const int i;
(void)(i + 17);
the lvalue-to-rvalue conversion for the subexpression "i" will turn it
from an lvalue expression (a DeclRefExpr) with type 'const int' into
an rvalue expression with type 'int'. Both C and C++ mandate this
conversion, and somehow we've slid through without implementing it.
We now have both DefaultFunctionArrayConversion and
DefaultFunctionArrayLvalueConversion, and which gets used depends on
whether we do the lvalue-to-rvalue conversion or not. Generally, we do
the lvalue-to-rvalue conversion, but there are a few notable
exceptions:
- the left-hand side of a '.' operator
- the left-hand side of an assignment
- a C++ throw expression
- a subscript expression that's subscripting a vector
Making this change exposed two issues with blocks:
- we were deducing const-qualified return types of non-class type
from a block return, which doesn't fit well
- we weren't always setting the known return type of a block when it
was provided with the ^return-type syntax
Fixes the current Clang-on-Clang compile failure and PR6076.
llvm-svn: 95167
|
| |
|
|
|
|
| |
declaration. Fixes radar 7590273.
llvm-svn: 95164
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
WHAT!?!
It turns out that Type::isPromotableIntegerType() was not considering
enumeration types to be promotable, so we would never do the
promotion despite having properly computed the promotion type when the
enum was defined. Various operations on values of enum type just
"worked" because we could still compute the integer rank of an enum
type; the oddity, however, is that operations such as "add an enum and
an unsigned" would often have an enum result type (!). The bug
actually showed up as a spurious -Wformat diagnostic
(<rdar://problem/7595366>), but in theory it could cause miscompiles.
In this commit:
- Enum types with a promotion type of "int" or "unsigned int" are
promotable.
- Tweaked the computation of promotable types for enums
- For all of the ABIs, treat enum types the same way as their
underlying types (*not* their promotion types) for argument passing
and return values
- Extend the ABI tester with support for enumeration types
llvm-svn: 95117
|
| |
|
|
| |
llvm-svn: 95104
|
| |
|
|
|
|
| |
without an initializer in C++ and thus fixes PR5451.
llvm-svn: 95098
|