- Extracted the reading of the tokens out into a separate function.
- Replace 'Argument' with 'Parameter' when referring to the identifiers of the macro definition (as opposed to the supplied arguments - MacroArgs - during the macro invocation).
This is in preparation for submitting patches for review to implement __VA_OPT__ which will otherwise just keep lengthening the HandleDefineDirective function and making it less comprehensible.
Thanks!
llvm-svn: 308157
This commit is a follow up to r302797 which added support for dependent
completions after the '.' and '->' operators. This commit adds support for
dependent completions after the '::' operator.
Differential Revision: https://reviews.llvm.org/D34173
llvm-svn: 305511
type is a TemplateSpecializationType or InjectedClassNameType
Fixes PR30847. Partially fixes PR20973 (first position only).
PR17614 is still not working, its expression has the dependent
builtin type. We'll have to teach the completion engine how to "resolve"
dependent expressions to fix it.
rdar://29818301
llvm-svn: 302797
If there is an unresolved member access AST node, and the base is
implicit, do not access/use it for generating candidate overloads for
code completion results.
Fixes PR31093.
llvm-svn: 298903
This commit adds context sensitive code completion support for the C++11
keywords that currently don't have completion results.
The following keywords are supported by this patch:
alignas
constexpr
static_assert
noexcept (as a function/method qualifier)
thread_local
The following special identifiers are also supported:
final (as a method qualifier or class qualifier)
override
rdar://29219185
Differential Revision: https://reviews.llvm.org/D28286
llvm-svn: 295001
We model deduction-guides as functions with a new kind of name that identifies
the template whose deduction they guide; the bulk of this patch is adding the
new name kind. This gives us a clean way to attach an extensible list of guides
to a class template in a way that doesn't require any special handling in AST
files etc (and we're going to need these functions we come to performing
deduction).
llvm-svn: 294266
methods from protocols and categories as well
Code completion results for class methods already include instance methods
from Objective-C root classes. This commit ensures that the results also include
instance methods from protocols that the root class implements and root class
categories as well.
rdar://28012953
Differential Revision: https://reviews.llvm.org/D27257
llvm-svn: 292932
Now when completing blocks properties that return void the block call completion
result shows up before the setter, otherwise the setter completion shows up
before the block call completion. We normally want to use the result of the
block call, so one typically wouldn't call a block that returns a non-void type
in a standalone statement.
rdar://28846153
Differential Revision: https://reviews.llvm.org/D26034
llvm-svn: 291232
This commit provides class property code completion results. It supports
explicit and implicit class properties, but the special block completion is done
only for explicit properties right now.
rdar://25636195
Differential Revision: https://reviews.llvm.org/D27053
llvm-svn: 289058
This commit fixes an incorrectly formatted Objective-C block parameter
placeholder in a code completion result. The incorrect parameter had a
redundant leading parenthesis.
rdar://25224416
llvm-svn: 287771
This commit changes the code completion results for block property setters:
The default block property result is now a block invocation rather than a simple
property reference.
rdar://28846196
Differential Revision: https://reviews.llvm.org/D26071
llvm-svn: 286363
dereferenced the pointer at this point, and these routines are
exclusively called after the parser encounters a code completion token.
Other code completion routines called at that point do not check for
null either, so this is clearly the current invariant expected in the
code.
This fixes another PVS-Studio found issue.
llvm-svn: 285980
This commit changes code completion results for Objective-C block properties:
clang now suggests an additional completion result that displays the block
property together with '=' and the block literal placeholder for the appropriate
readwrite block properties.
This commit uses a simple heuristic to determine when it's appropriate to
suggest a setter completion for block properties: the additional block setter
completion is provided iff the member access that's being completed is a
standalone statement.
rdar://28481726
Differential Revision: https://reviews.llvm.org/D25520
llvm-svn: 284472
This commit extracts a new function named `formatBlockPlaceholder` from
the function `FormatFunctionParameter` so that it can be reused in follow-up
commits that improve code completion for block property setters.
Differential Revision: https://reviews.llvm.org/D25519
llvm-svn: 284468
This commit extracts a new function named `findTypeLocationForBlockDecl` from
the function `FormatFunctionParameter` so that it can be reused in follow-up
commits that improve code completion for block property setters.
Differential Revision: https://reviews.llvm.org/D25519
llvm-svn: 284467
This commit improves code completion for properties that are declared in
Objective-C protocols by making sure that properties show up in completions
when they are accessed through a qualified id.
rdar://24426041
Differential Revision: https://reviews.llvm.org/D25436
llvm-svn: 284007
an identifier table lookup, *and* copy the LangOptions (including various
std::vector<std::string>s). Twice. We call this function once each time we start
parsing a declaration specifier sequence, and once for each call to Sema::Diag.
This reduces the compile time for a sample .c file from the linux kernel by 20%.
llvm-svn: 270009
This patch implements __unaligned (MS extension) as a proper type qualifier
(before that, it was implemented as an ignored attribute).
It also fixes PR27367 and PR27666.
Differential Revision: http://reviews.llvm.org/D20103
llvm-svn: 269220
This patch implements __unaligned (MS extension) as a proper type qualifier
(before that, it was implemented as an ignored attribute).
It also fixes PR27367.
Differential Revision: http://reviews.llvm.org/D19654
llvm-svn: 268727
This patch implements __unaligned as a type qualifier; before that, it was
modeled as an attribute. Proper mangling of __unaligned is implemented as well.
Some OpenCL code/tests are tangenially affected, as they relied on existing
number and sizes of type qualifiers.
Differential Revision: http://reviews.llvm.org/D18596
llvm-svn: 266415
Currently we return no results when completing inside of the brackets in
a 'char foo[]' declaration. Let the generic expression completion code
handle it instead. We could get fancier here (e.g. filter non-constant
expressions in contexts where VLAs are not allowed), but it's a strict
improvement over the existing version.
llvm-svn: 261217
Add "enum ObjCPropertyQueryKind" to a few APIs that used to only take the name
of the property: ObjCPropertyDecl::findPropertyDecl,
ObjCContainerDecl::FindPropertyDeclaration,
ObjCInterfaceDecl::FindPropertyVisibleInPrimaryClass,
ObjCImplDecl::FindPropertyImplDecl, and Sema::ActOnPropertyImplDecl.
ObjCPropertyQueryKind currently has 3 values:
OBJC_PR_query_unknown, OBJC_PR_query_instance, OBJC_PR_query_class
This extra parameter specifies that we are looking for an instance property with
the given name, or a class property with the given name, or any property with
the given name (if both exist, the instance property will be returned).
rdar://23891898
llvm-svn: 259070
All current properties are instance properties.
This is the second patch in a series of patches to support class properties
in addition to instance properties in objective-c.
rdar://23891898
llvm-svn: 258824
declaration. This fixes an issue where we would reject (due to a claimed
ambiguity) a case where lookup finds multiple NamespaceAliasDecls from
different scopes that nominate the same namespace.
The C++ standard doesn't make it clear that such a case is in fact valid (which
I'm working on fixing), but there are no relevant rules that distinguish using
declarations and namespace alias declarations here, so it makes sense to treat
them the same way.
llvm-svn: 256601
is complete (with an error produced if not) and a function that merely queries
whether the type is complete. Either way we'll trigger instantiation if
necessary, but only the former will diagnose and recover from missing module
imports.
The intent of this change is to prevent a class of bugs where code would call
RequireCompleteType(..., 0) and then ignore the result. With modules, we must
check the return value and use it to determine whether the definition of the
type is visible.
This also fixes a debug info quality issue: calls to isCompleteType do not
trigger the emission of debug information for a type in limited-debug-info
mode. This allows us to avoid emitting debug information for type definitions
in more cases where we believe it is safe to do so.
llvm-svn: 256049
Previously, __weak was silently accepted and ignored in MRC mode.
That makes this a potentially source-breaking change that we have to
roll out cautiously. Accordingly, for the time being, actual support
for __weak references in MRC is experimental, and the compiler will
reject attempts to actually form such references. The intent is to
eventually enable the feature by default in all non-GC modes.
(It is, of course, incompatible with ObjC GC's interpretation of
__weak.)
If you like, you can enable this feature with
-Xclang -fobjc-weak
but like any -Xclang option, this option may be removed at any point,
e.g. if/when it is eventually enabled by default.
This patch also enables the use of the ARC __unsafe_unretained qualifier
in MRC. Unlike __weak, this is being enabled immediately. Since
variables are essentially __unsafe_unretained by default in MRC,
the only practical uses are (1) communication and (2) changing the
default behavior of by-value block capture.
As an implementation matter, this means that the ObjC ownership
qualifiers may appear in any ObjC language mode, and so this patch
removes a number of checks for getLangOpts().ObjCAutoRefCount
that were guarding the processing of these qualifiers. I don't
expect this to be a significant drain on performance; it may even
be faster to just check for these qualifiers directly on a type
(since it's probably in a register anyway) than to do N dependent
loads to grab the LangOptions.
rdar://9674298
llvm-svn: 251041
The outer nullability is transferred from the declaration to the implementation so including them is redundant.
The inner ones are not transferred so they are kept to match the exact types. When we transfer the inner ones as well
adding them in the implementation will become redundant and we should strip those as well.
rdar://21737451
llvm-svn: 243119