| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
<stdatomic.h> header.
In passing, fix LanguageExtensions to note that C11 and C++11 are no longer
"upcoming standards" but are now actually standardized.
llvm-svn: 154513
|
|
|
|
| |
llvm-svn: 154501
|
|
|
|
| |
llvm-svn: 154499
|
|
|
|
|
|
|
|
| |
incomplete type, keep track of the actual type that was
incomplete. Otherwise, we might fail to produce a diagnostic. Fixes
PR12498.
llvm-svn: 154432
|
|
|
|
|
|
| |
non-type template parameter of pointer type is not a constant expression.
llvm-svn: 154424
|
|
|
|
|
|
|
| |
providing code completions for Objective-C method declarations. Fixes
<rdar://problem/11164498>.
llvm-svn: 154421
|
|
|
|
|
|
|
| |
'public', 'private', or 'protected', unless code completion patterns
are enabled. Fixes <rdar://problem/11189132>.
llvm-svn: 154413
|
|
|
|
|
|
|
| |
seem to get called any more. Also add an assert in
isModifiableLvalue.
llvm-svn: 154410
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
code-completion related strings specific to a translation unit (ASTContext and related data)
CodeCompletionAllocator does such limited caching, by caching the name assigned
to a DeclContext*, but that is not the appropriate place since that object has
a lifetime that can extend beyond that of an ASTContext.
Introduce CodeCompletionTUInfo which will be always tied to a translation unit
to do this kind of caching and move the caching of CodeCompletionAllocator into this
object, and propagate it to all the places where it will be needed.
The plan is to extend the caching where appropriate, using CodeCompletionTUInfo,
to avoid re-calculating code-completion strings.
Part of rdar://10796159.
llvm-svn: 154408
|
|
|
|
|
|
|
| |
Richard's feedback, to properly catch non-constant expressions and
type mismatches. Finishes <rdar://problem/11193097>.
llvm-svn: 154407
|
|
|
|
|
|
| |
expression enterring IsConstProperty function.
llvm-svn: 154406
|
|
|
|
|
|
|
|
|
|
|
|
| |
base-class subojects.
Incidentally, thinking about virtual bases makes it clear to me that
we're not appropriately computing the access to the virtual base's
member because we're not computing the best possible access to the
virtual base at all; in fact, we're basically assuming it's public.
I'll file a separate PR about that.
llvm-svn: 154346
|
|
|
|
|
|
|
|
| |
to define a special member function as deleted so that it properly
establishes an object context for the accesses to the base subobject
members.
llvm-svn: 154343
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Specifically, using a an integer outside [0, 1] as a boolean constant seems to
be an easy mistake to make with things like "x == a || b" where the author
intended "x == a || x == b".
The bug caused by calling SkipUntil with three token kinds was also identified
by a VC diagnostic & reported by Francois Pichet as review feedback for my
commit r154163. I've included test cases to verify the error recovery that was
broken/poorly implemented due to this bug.
The other fix (lib/Sema/SemaExpr.cpp) seems like that code was never actually
reached in any of Clang's tests & is related to Objective C features I'm not
familiar with, so I've not been able to construct a test case for it. Perhaps
someone else can.
llvm-svn: 154325
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- The [class.protected] restriction is non-trivial for any instance
member, even if the access lacks an object (for example, if it's
a pointer-to-member constant). In this case, it is equivalent to
requiring the naming class to equal the context class.
- The [class.protected] restriction applies to accesses to constructors
and destructors. A protected constructor or destructor can only be
used to create or destroy a base subobject, as a direct result.
- Several places were dropping or misapplying object information.
The standard could really be much clearer about what the object type is
supposed to be in some of these accesses. Usually it's easy enough to
find a reasonable answer, but still, the standard makes a very confident
statement about accesses to instance members only being possible in
either pointer-to-member literals or member access expressions, which
just completely ignores concepts like constructor and destructor
calls, using declarations, unevaluated field references, etc.
llvm-svn: 154248
|
|
|
|
|
|
|
| |
template parameters of pointer, pointer-to-member, or nullptr_t
type in C++11. Fixes PR9700 / <rdar://problem/11193097>.
llvm-svn: 154219
|
|
|
|
|
|
| |
to a lockable type from error to warning.
llvm-svn: 154198
|
|
|
|
|
|
|
|
|
| |
the template instantiation of statement-expressions.
I think it was jyasskin who had a crashing testcase in this area;
hopefully this fixes it and he can find his testcase and check it in.
llvm-svn: 154189
|
|
|
|
|
|
|
|
|
| |
root class is intentionally declared.
The warning this inhibits, -Wobjc-root-class, is opt-in for now. However, all clang unit tests that would trigger
the warning have been updated to use -Wno-objc-root-class. <rdar://problem/7446698>
llvm-svn: 154187
|
|
|
|
| |
llvm-svn: 154173
|
|
|
|
|
|
| |
a namespace alias declaration.
llvm-svn: 154138
|
|
|
|
|
|
| |
are duplicated via a typedef. Patch by Tim Northover.
llvm-svn: 154136
|
|
|
|
|
|
| |
conditionals. Patch by Tim Northover.
llvm-svn: 154134
|
|
|
|
|
|
|
| |
declared in its adopted protocol when another category declares it
because that category will implement it. // rdar://11186449
llvm-svn: 154132
|
|
|
|
|
|
|
|
|
|
|
|
| |
* s/nonstatic/non-static/ in the diagnostics, since the latter form outvoted
the former by 28-2 in our diagnostics.
* Fix the "use of member in static member function" diagnostic to correctly
detect this situation inside a block or lambda.
* Produce a more specific "invalid use of non-static member" diagnostic for
the case where a nested class member refers to a member of a
lexically-surrounding class.
llvm-svn: 154073
|
|
|
|
|
|
|
| |
std::initializer_list<T> so long as <T> is known. This conversion has
identity rank.
llvm-svn: 154065
|
|
|
|
|
|
| |
or function with internal linkage as a non-type template argument.
llvm-svn: 154053
|
|
|
|
|
|
|
| |
in arc mode and opted-in with -Wreceiver-is-weak flag.
// rdar://10225276
llvm-svn: 154042
|
|
|
|
|
|
|
|
|
|
| |
number + context) to the point where we initially start defining the
lambda, so that the linkage won't change when that information is made
available. Fixes the assertion in <rdar://problem/11182962>.
Plus, actually mangle the context of lambdas properly.
llvm-svn: 154029
|
|
|
|
|
|
|
|
|
|
| |
a type specifier and can be combined with unsigned. This allows libstdc++4.7 to
be used with clang in c++98 mode.
Several other changes are still required for libstdc++4.7 to work with clang in
c++11 mode.
llvm-svn: 153999
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
be sure to perform the argument type adjustments in
[temp.deduct.call]p2, e.g., array decay.
And, when performing these deductions in the context of 'auto', make
sure that we're deducing the P' in std::initializer_list<P'> rather
than the whole initializer list.
Together, this makes code like
for( auto s : {"Deferred", "New", "Open", "Review"}) { }
work properly.
llvm-svn: 153998
|
|
|
|
|
|
| |
list-initialization. Loosen an over-eager assertion to fix PR12453.
llvm-svn: 153995
|
|
|
|
|
|
|
|
| |
for converting an empty list to a scalar, be sure to initialize
the source and destination types so that comparison of conversion
sequences will work in case there are multiple viable candidates.
llvm-svn: 153993
|
|
|
|
|
|
|
|
|
| |
keep the latter.
No test. This was noticed when poking around something else with GDB. I'm not
able to figure out a testcase that would break due to this bug. Sorry.
llvm-svn: 153992
|
|
|
|
|
|
|
| |
statement-expressions. Prevents cleanups and such from being
claimed by the first full-expression in the block.
llvm-svn: 153989
|
|
|
|
| |
llvm-svn: 153985
|
|
|
|
|
|
|
|
| |
a view over the contents of a DeclContext without exposing the implementation
details of the StoredDeclsMap. Use this in LookupVisibleDecls to find the
visible declarations. Fixes PR12339!
llvm-svn: 153970
|
|
|
|
|
|
| |
looking up visible decls.
llvm-svn: 153967
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Infinite recursion was happening when DiagnoseInvalidRedeclaration
called ActOnFunctionDeclarator to check if a typo correction works when
the correction was just to the nested-name-specifier because the wrong
DeclContext was being passed in. Unlike a number of functions
surrounding typo correction, the DeclContext passed in for a function is
the context of the function name after applying any nested name
specifiers, not the lexical DeclContext where the
function+nested-name-specifier appears.
llvm-svn: 153962
|
|
|
|
|
|
| |
'copy assignment operator'.
llvm-svn: 153897
|
|
|
|
|
|
| |
explicitly, deleted in all relevant cases, and explain why.
llvm-svn: 153894
|
|
|
|
| |
llvm-svn: 153885
|
|
|
|
|
|
|
|
|
|
|
| |
move constructor/move assignment operator are not declared, rather than being
defined as deleted, so move operations on the derived class fall back to
copying rather than moving.
If a move operation on the derived class is explicitly defaulted, the
unmovable subobject will be copied instead of being moved.
llvm-svn: 153883
|
|
|
|
|
|
| |
dependent contexts.
llvm-svn: 153858
|
|
|
|
| |
llvm-svn: 153849
|
|
|
|
|
|
| |
member function is deleted.
llvm-svn: 153773
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the nested-name-specifier (e.g., because it is dependent), do not
error even though we can't represent it in the AST at this point.
This is a horrible, horrible hack. The actual feature we still need to
implement (for C++98!) is covered by PR12292. However, we used to
silently accept this code, so when we recently started rejecting it we
caused some regressions (e.g., <rdar://problem/11147355>). This hack
brings us back to the passable-but-not-good state we had previously.
llvm-svn: 153752
|
|
|
|
|
|
|
| |
The way we handle this implicitly removes the ability to use
property l-values in this position, but that's really okay.
llvm-svn: 153729
|
|
|
|
|
|
| |
in ARC, under the usual reasoning limiting the use of __autoreleasing.
llvm-svn: 153725
|
|
|
|
|
|
| |
methods with related result types. PR12384.
llvm-svn: 153716
|