| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
entering the context of a nested-name-specifier. Fixes
<rdar://problem/10397846>.
llvm-svn: 143967
|
| |
|
|
| |
llvm-svn: 143907
|
| |
|
|
| |
llvm-svn: 142478
|
| |
|
|
| |
llvm-svn: 142056
|
| |
|
|
|
|
|
| |
'final', and don't accept (then silently discard) braced init lists in C++98
new-expressions.
llvm-svn: 142048
|
| |
|
|
|
|
| |
Lack of half FP was a regression compared to llvm-gcc.
llvm-svn: 142016
|
| |
|
|
|
|
|
| |
delimiter pairs and detect when we exceed the implementation limit for
nesting depth, from Aaron Ballman!
llvm-svn: 141782
|
| |
|
|
|
|
|
|
|
|
|
| |
and DefaultFunctionArrayLvalueConversion. To prevent
significant regression for should-this-be-a-call fixits,
and to repair some such regression from the introduction of
bound member placeholders, make those placeholder checks
try to build calls appropriately. Harden the build-a-call
logic while we're at it.
llvm-svn: 141738
|
| |
|
|
| |
llvm-svn: 140407
|
| |
|
|
| |
llvm-svn: 140367
|
| |
|
|
|
|
|
| |
erronously trigger the digraph correction fix-it. Include a new test to catch
this in the future.
llvm-svn: 140175
|
| |
|
|
|
|
| |
It already works (and is useful with) macro locs as well.
llvm-svn: 140057
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For instance:
template <class T> void E() {};
class F {};
void test() {
::E<::F>();
E<::F>();
}
Gives the following error messages:
error: found '<::' after a template name which forms the
digraph '<:' (aka '[') and a ':', did you mean '< ::'?
::E<::F>();
^~~
< ::
error: expected expression
E<::F>();
^
error: expected ']'
note: to match this '['
E<::F>();
This patch adds the digraph fix-it check right before the name lookup,
moves the shared checking code to a new function, and adds new
tests to catch future regressions.
llvm-svn: 140039
|
| |
|
|
|
|
|
|
| |
that this flag must be used only for Microsoft extensions and not emulation; to avoid confusion with the new LangOptions::MicrosoftMode flag.
Many of the code now under LangOptions::MicrosoftExt will eventually be moved under the LangOptions::MicrosoftMode flag.
llvm-svn: 139987
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we would cut off the source file buffer at the code-completion
point; this impeded code-completion inside C++ inline methods and,
recently, with buffering ObjC methods.
Have the code-completion inserted into the source buffer so that it can
be buffered along with a method body. When we actually hit the code-completion
point the cut-off lexing or parsing.
Fixes rdar://10056932&8319466
llvm-svn: 139086
|
| |
|
|
|
|
| |
David Blaikie!
llvm-svn: 136876
|
| |
|
|
|
|
|
|
| |
LLVM.h imports
them into the clang namespace.
llvm-svn: 135852
|
| |
|
|
|
|
|
|
|
|
|
|
| |
throw-expressions, such that we don't consider the NRVO when the
non-volatile automatic object comes from outside the innermost try
scope (C++0x [class.copymove]p13). In C++98/03, our ASTs were
incorrect but it didn't matter because IR generation doesn't actually
apply the NRVO here. In C++0x, however, we were moving from an object
when in fact we should have copied from it. Fixes PR10142 /
<rdar://problem/9714312>.
llvm-svn: 134548
|
| |
|
|
|
|
|
|
|
|
|
|
| |
ownership, if the
cast type has no ownership specified, implicitly "transfer" the ownership of the cast'ed type
to the cast type:
id x;
(NSString**)&x; // Casting as (__strong NSString**).
llvm-svn: 134275
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
ownership, if the
cast type has no ownership specified, implicitly "transfer" the ownership of the cast'ed type
to the cast type:
id x;
static_cast<NSString**>(&x); // Casting as (__strong NSString**).
This currently only works for C++ named casts, C casts to follow.
llvm-svn: 134273
|
| |
|
|
|
|
| |
from Sema::GetTypeForDeclarator. No functionality change.
llvm-svn: 133987
|
| |
|
|
|
|
|
|
|
|
| |
resources that, while their
lifetime is well-known and restricted, cleaning them up manually is easy to miss and cause a leak.
Use it to plug the leaking of TemplateIdAnnotation objects. rdar://9634138.
llvm-svn: 133610
|
| |
|
|
| |
llvm-svn: 132662
|
| |
|
|
| |
llvm-svn: 131633
|
| |
|
|
| |
llvm-svn: 131270
|
| |
|
|
|
|
|
| |
modify the semantics slightly to accomodate default constructors (I
hope).
llvm-svn: 131087
|
| |
|
|
| |
llvm-svn: 130775
|
| |
|
|
|
|
|
|
|
|
|
| |
As might be surmised from their names, these aren't type traits, they're
expression traits. Amazingly enough, they're expression traits that we
have, and fully implement. These "type" traits are even parsed from the
same tokens as the expression traits. Luckily, the parser only tried the
expression trait parsing for these tokens, so this was all just a pile
of dead code.
llvm-svn: 130643
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
defines to real types.
Otherwise statements like:
__int64 var = __int64(0);
would be expanded to:
long long var = long long(0);
and fail to compile.
llvm-svn: 130369
|
| |
|
|
|
|
|
|
|
|
| |
Patch authored by John Wiegley.
These are array type traits used for parsing code that employs certain
features of the Embarcadero C++ compiler: __array_rank(T) and
__array_extent(T, Dim).
llvm-svn: 130351
|
| |
|
|
|
|
|
|
|
|
| |
Patch authored by John Wiegley.
These type traits are used for parsing code that employs certain features of
the Embarcadero C++ compiler. Several of these constructs are also desired by
libc++, according to its project pages (such as __is_standard_layout).
llvm-svn: 130342
|
| |
|
|
|
|
|
| |
creating a type-annotation token rather than jumping into the
declaration parsing.
llvm-svn: 130293
|
| |
|
|
|
|
|
|
|
| |
Patch authored by David Abrahams.
These two expression traits (__is_lvalue_expr, __is_rvalue_expr) are used for
parsing code that employs certain features of the Embarcadero C++ compiler.
llvm-svn: 130122
|
| |
|
|
|
|
|
|
| |
'__is_literal' type trait for GCC compatibility. At least one relased
version if libstdc++ uses this name for the trait despite it not being
documented anywhere.
llvm-svn: 130078
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This introduces a few APIs on the AST to bundle up the standard-based
logic so that programmatic clients have access to exactly the same
behavior.
There is only one serious FIXME here: checking for non-trivial move
constructors and move assignment operators. Those bits need to be added
to the declaration and accessors provided.
This implementation should be enough for the uses of __is_trivial in
libstdc++ 4.6's C++98 library implementation.
Ideas for more thorough test cases or any edge cases missing would be
appreciated. =D
llvm-svn: 130057
|
| |
|
|
|
|
| |
sorted in order to prepare for adding some new ones.
llvm-svn: 130056
|
| |
|
|
| |
llvm-svn: 130042
|
| |
|
|
|
|
| |
warnings I introduced lately.
llvm-svn: 129986
|
| |
|
|
|
|
| |
"new" expression. This matches GCC's parser. Test is forthcoming.
llvm-svn: 129592
|
| |
|
|
|
|
|
|
| |
and is interpreted as "[:" because of the digraph "<:". When found, give an error with a fix-it to add whitespace between the "<" and "::".
Patch by Richard Trieu! Plus a small tweak from me to deal with one of the tokens coming from a macro.
llvm-svn: 129540
|
| |
|
|
|
|
|
|
|
|
|
| |
without the "template" keyword.
For example:
typename C1<T>:: /*template*/ Iterator<0> pos;
Also the error is downgraded to an ExtWarn in Microsoft mode.
llvm-svn: 128387
|
| |
|
|
|
|
|
|
|
| |
AttributeLists do not accumulate over the lifetime of parsing, but are
instead reused. Also make the arguments array not require a separate
allocation, and make availability attributes store their stuff in
augmented memory, too.
llvm-svn: 128209
|
| |
|
|
|
|
| |
should be resolvable, from Faisal Vali!
llvm-svn: 127521
|
| |
|
|
|
|
|
|
| |
to cope with non-type templates by providing appropriate
errors. Previously, we would either assert, crash, or silently build a
dependent type when we shouldn't. Fixes PR9226.
llvm-svn: 127037
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
template specialization types. This also required some parser tweaks,
since we were losing track of the nested-name-specifier's source
location information in several places in the parser. Other notable
changes this required:
- Sema::ActOnTagTemplateIdType now type-checks and forms the
appropriate type nodes (+ source-location information) for an
elaborated-type-specifier ending in a template-id. Previously, we
used a combination of ActOnTemplateIdType and
ActOnTagTemplateIdType that resulted in an ElaboratedType wrapped
around a DependentTemplateSpecializationType, which duplicated the
keyword ("class", "struct", etc.) and nested-name-specifier
storage.
- Sema::ActOnTemplateIdType now gets a nested-name-specifier, which
it places into the returned type-source location information.
- Sema::ActOnDependentTag now creates types with source-location
information.
llvm-svn: 126808
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
nested-name-speciciers within elaborated type names, e.g.,
enum clang::NestedNameSpecifier::SpecifierKind
Fixes in this iteration include:
(1) Compute the type-source range properly for a dependent template
specialization type that starts with "template template-id ::", as
in a member access expression
dep->template f<T>::f()
This is a latent bug I triggered with this change (because now we're
checking the computed source ranges for dependent template
specialization types). But the real problem was...
(2) Make sure to set the qualifier range on a dependent template
specialization type appropriately. This will go away once we push
nested-name-specifier locations into dependent template
specialization types, but it was the source of the
valgrind errors on the buildbots.
llvm-svn: 126765
|
| |
|
|
|
|
| |
location information for elaborated types. *sigh*
llvm-svn: 126753
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
information for qualifier type names throughout the parser to address
several problems.
The commit message from r126737:
Push nested-name-specifier source location information into elaborated
name types, e.g., "enum clang::NestedNameSpecifier::SpecifierKind".
Aside from the normal changes, this also required some tweaks to the
parser. Essentially, when we're looking at a type name (via
getTypeName()) specifically for the purpose of creating an annotation
token, we pass down the flag that asks for full type-source location
information to be stored within the returned type. That way, we retain
source-location information involving nested-name-specifiers rather
than trying to reconstruct that information later, long after it's
been lost in the parser.
With this change, test/Index/recursive-cxx-member-calls.cpp is showing
much improved results again, since that code has lots of
nested-name-specifiers.
llvm-svn: 126748
|
| |
|
|
|
|
| |
information. Fixes <rdar://problem/9063643>.
llvm-svn: 126721
|
| |
|
|
|
|
|
|
|
|
|
|
| |
nested-name-specifier, e.g.,
T::template apply<U>::
represent the dependent template name specialization as a
DependentTemplateSpecializationType, rather than a
TemplateSpecializationType with a dependent TemplateName.
llvm-svn: 126593
|