Age | Commit message (Collapse) | Author |
|
- References to ObjC bit-field ivars are bit-field lvalues;
fixes rdar://13794269, which got me started down this.
- Introduce Expr::refersToBitField, switch a couple users to
it where semantically important, and comment the difference
between this and the existing API.
- Discourage Expr::getBitField by making it a bit longer and
less general-sounding.
- Lock down on const_casts of bit-field gl-values until we
hear back from the committee as to whether they're allowed.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181252 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181166 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181158 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
constructor from None
Patch by Robert Wilhelm.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181139 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Missing (somewhat ironically) is support for the new deduction rules
in lambda functions, plus PCH support for return type patching.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181108 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
to use. This makes very little difference right now (other than suppressing
follow-on errors in some cases), but will matter more once we support deduced
return types (we don't want expressions with undeduced return types in the
AST).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181107 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Patch by Robert Wilhelm!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180724 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
a trailing return type in that class's body.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179941 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
templates, from Alexander Zinenko!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179680 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
It was being used correctly, but it is a very dangerous API to have around.
Instead, move the logic from the filtering to when we are deciding if we should
link two decls.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179523 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
have integral values.
We were assuming that any expression used as a converted constant
expression would either not have a folded constant value or would be
an integer, which is not the case for some ill-formed constant
expressions. Because converted constant expressions are only used
where integral values are expected, we can simply treat this as an
error path. If that ever changes, we'll need to widen the interface of
Sema::CheckConvertedConstantExpression() anyway.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179068 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
When two template decls with the same name are used in this diagnostic,
force them to print their qualified names. This changes the bad message of:
candidate template ignored: could not match 'array' against 'array'
to the better message of:
candidate template ignored: could not match 'NS2::array' against 'NS1::array'
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179056 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
declaration. Patch by Stephen Lin!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178698 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
returns consistent results with invalid types.
When Sema::RequireCompleteType() is given a class template
specialization type that then fails to instantiate, it returns
'true'. On subsequent invocations, it can return false. Make sure that
this difference doesn't change the result of
Sema::CompareReferenceRelationship, which is expected to remain stable
while we're checking an initialization sequence.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178088 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Before this patch we would compute the linkage lazily and cache it. When the
AST was modified in ways that could change the value, we would invalidate the
cache.
That was fairly brittle, since any code could ask for the a linkage before
the correct value was available.
We should change the API to one where the linkage is computed explicitly and
trying to get it when it is not available asserts.
This patch is a first step in that direction. We still compute the linkage
lazily, but instead of invalidating a cache, we assert that the AST
modifications didn't change the result.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176999 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This would error in C++ mode unless the variable also had a cv
qualifier.
e.g.
__attribute__((address_space(2))) float foo = 1.0f; would error but
__attribute__((address_space(2))) const float foo = 1.0f; would not.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176121 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Weather we should give C language linkage to functions and variables with
internal linkage probably depends on how much code assumes it. The standard
says they should have no language linkage, but gcc and msvc assign them
C language linkage.
This commit removes the hack that was preventing the mangling on static
functions declare in extern C contexts. It is an experiment to see if we
can implement the rules in the standard.
If it turns out that many users depend on these functions and variables
having C language linkage, we should change isExternC instead and try
to convince the CWG to change the standard.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175937 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
static functions in extern "C" contexts are mangled. Should fix the
bootstrap.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175132 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
I added hasCLanguageLinkage while fixing some language linkage bugs some
time ago so that I wouldn't have to check all users of isExternC. It turned
out to be a much longer detour than expected, but this patch finally
merges the two again. The isExternC function now implements just the
standard notion of having C language linkage.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175119 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
MarkMemberReferenced instead of marking functions referenced directly. An audit
of callers to MarkFunctionReferenced and DiagnoseUseOfDecl also caused a few
other changes:
* don't mark functions odr-used when considering them for an initialization
sequence. Do mark them referenced though.
* the function nominated by the cleanup attribute should be diagnosed.
* operator new/delete should be diagnosed when building a 'new' expression.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174951 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
OpenCL builtin functions.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174630 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
restrictions.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174601 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
operators.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174584 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
have a direct mismatch between some component of the template and some
component of the argument. The diagnostic now says what the mismatch was, but
doesn't yet say which part of the template doesn't match.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174039 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
in the one case where we've already factored out a reason code.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174036 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
object argument type for a member call.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173554 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
overloaded binary operators.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173315 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
functionality change!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173314 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
operations (as opposed to storage only half/fp16).
Also add some semantic checks for OpenCL half types.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173254 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
on redeclarations, since that makes us pick wrong prior declarations under
some circumstances.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172384 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
we know whether it is static.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172376 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
brought into 'clang' namespace by clang/Basic/LLVM.h
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172323 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Thanks Eli Friedman for noticing it.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172292 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@171367 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This patch moves hasCLanguageLinkage to be VarDecl and FunctionDecl methods
so that they can be used from SemaOverload.cpp and then fixes the logic
in Sema::IsOverload.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@171193 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
function is selected by overload resolution.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@171190 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
it might instead be a TranslationUnitDecl.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@170976 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
per review discussion in r170365
This does limit these typedefs to being sequences, but no current usage
requires them to be contiguous (we could expand this to a more general
iterator pair range concept at some point).
Also, it'd be nice if SmallVector were constructible directly from an ArrayRef
but this is a bit tricky since ArrayRef depends on SmallVectorBaseImpl for the
inverse conversion. (& generalizing over all range-like things, while nice,
would require some nontrivial SFINAE I haven't thought about yet)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@170482 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
array from a braced-init-list. There seems to be a core wording wart
here (it suggests we should be testing whether the elements of the init
list are implicitly convertible to the array element type, not whether
there is an implicit conversion sequence) but our prior behavior appears
to be a bug, not a deliberate effort to implement the standard as written.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169690 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
uncovered.
This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/utils/sort_includes.py
script over the files.
I also manually added quite a few missing headers that were uncovered by
shuffling the order or moving headers up to be main-module-headers.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169237 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
expose only the iterators instead.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@168770 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
a CXXDefaultArgExpr.
Fixes PR13758.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@168521 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
and we resolve it to a specific function based on the type which it's used as,
don't forget to mark it as referenced.
Fixes a regression introduced in r167514.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167918 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
add functions to namespace 'std', also filter out namespaces with '__' anywhere
in the name.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167786 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
I couldn't think of a way to make an operator() invalid without returning
earlier from this function other than making it static, so no new test.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167609 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Patch from Brian Brooks!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167604 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
function that takes a const Foo&, where Foo is convertible from a large number
of pointer types, we print ALL the overloads, no matter the setting of
-fshow-overloads.
There is potential follow-on work in unifying the "print candidates, but not
too many" logic between OverloadCandidateSet::NoteCandidates and
ImplicitConversionSequence::DiagnoseAmbiguousConversion.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167596 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
instantiate it if it can be instantiated and implicitly define it if it can be
implicitly defined. This matches g++'s approach. Remove some cases from
SemaOverload which were marking functions as referenced when just planning how
overload resolution would proceed; such cases are not actually references.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167514 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166520 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
namespace.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166194 91177308-0d34-0410-b5e6-96231b3b80d8
|