| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
| |
TypeSpecifierType into scoped enums with underlying types.
- Since these enums are used as bit-fields - for the bit-fields to be interpreted as unsigned, the underlying type must be specified as unsigned.
Previous failed attempt - wherein I did not specify an underlying type - was the sum of:
https://reviews.llvm.org/rC321614
https://reviews.llvm.org/rC321615
llvm-svn: 321622
|
|
|
|
|
|
|
|
| |
- the enum changes to TypeSpecifierType are breaking some tests - and will require a more careful integration.
Sorry about rushing these changes - thought I could sneak them in prior to heading out for new years ;)
llvm-svn: 321616
|
|
|
|
|
|
|
|
| |
TypeSpecifierType into scoped enums.
llvm-svn: 321614
|
|
|
|
| |
llvm-svn: 321590
|
|
|
|
|
|
| |
UnqualifiedIdKind.
llvm-svn: 321574
|
|
|
|
|
|
| |
Note, we don't do any bitwise manipulations when using them.
llvm-svn: 321546
|
|
|
|
|
|
| |
changing the C++1z terminology over to C++17. NFC intended, these are all mechanical changes.
llvm-svn: 319688
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
modifiers
With enabled CINDEXTEST_CODE_COMPLETE_PATTERNS env option (which enables
IncludeCodePatterns in completion options) code completion after colon
currently suggests access modifiers with 2 completion chunks which is
incorrect.
Example:
class A : <Cursor>B
{
}
Currently we get 'NotImplemented:{TypedText public}{Colon :} (40)'
but the correct line is just 'NotImplemented:{TypedText public} (40)'
The fix introduces more specific scope that occurs between ':' and '{'
It allows us to determine when we don't need to add ':' as a second
chunk to the public/protected/private access modifiers.
Patch by Ivan Donchevskii!
Differential Revision: https://reviews.llvm.org/D38618
llvm-svn: 316436
|
|
|
|
|
|
| |
use of [[]] attributes in all language modes. This is the initial implementation of WG14 N2165, which is a proposal to add [[]] attributes to C2x, but also allows you to enable these attributes in C++98, or disable them in C++11 or later.
llvm-svn: 315856
|
|
|
|
|
|
| |
attributes-on-namespaces-and-enumerators feature.
llvm-svn: 315784
|
|
|
|
|
|
|
| |
This would be trivial, except that our in-memory and serialized representations
for FieldDecls assumed that this can't happen.
llvm-svn: 311867
|
|
|
|
| |
llvm-svn: 310805
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Allow ODR for ObjC/C in the sense that we won't keep more that
one definition around (merge them). However, ensure the decl
pass the structural compatibility check in C11 6.2.7/1, for that,
reuse the structural equivalence checks used by the ASTImporter.
Few other considerations:
- Create error diagnostics for tag types mismatches and thread
them into the structural equivalence checks.
- Note that by doing this we only support redefinition between types
that are considered "compatible types" by C.
This is mixed approach of the suggestions discussed in
http://lists.llvm.org/pipermail/cfe-dev/2017-March/053257.html
Differential Revision: https://reviews.llvm.org/D31778
rdar://problem/31909368
llvm-svn: 306918
|
|
|
|
| |
llvm-svn: 306789
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
definition or non-reference class type.
The crash occurs when there is a template parameter list in a class that
is missing the closing angle bracket followed by a definition of a
struct. For example:
class C0 {
public:
template<typename T, typename T1 = T // missing closing angle bracket
struct S0 {};
C0() : m(new S0<int>) {}
S0<int> *m;
};
This happens because the parsed struct is added to the scope of the
enclosing class without having its access specifier set, which results
in an assertion failure in SemaAccess.cpp later.
This commit fixes the crash by adding the parsed struct to the enclosing
file scope and marking structs as invalid if they are defined in
template parameter lists.
rdar://problem/31783961
rdar://problem/19570630
Differential Revision: https://reviews.llvm.org/D33606
llvm-svn: 306317
|
|
|
|
|
|
|
| |
This fixes missing lambda-captures for variables referenced only inside a
static_assert (!), among other things.
llvm-svn: 304760
|
|
|
|
| |
llvm-svn: 304473
|
|
|
|
|
|
|
|
|
|
| |
We were incorrectly setting PrevTokLocation to the first token in the
annotation token instead of the last when consuming it. To fix this without
adding a complex switch to the hot path through ConsumeToken, we now have a
ConsumeAnnotationToken function for consuming annotation tokens in addition
to the other Consume*Token special case functions.
llvm-svn: 303372
|
|
|
|
| |
llvm-svn: 302737
|
|
|
|
|
|
| |
https://reviews.llvm.org/D32879
llvm-svn: 302255
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
[LWG 2911](http://cplusplus.github.io/LWG/lwg-defects.html#2911) adds `std::is_aggregate` to the library, which requires a new builtin trait. This patch implements `__is_aggregate`.
Reviewers: rsmith, majnemer, aaron.ballman
Reviewed By: aaron.ballman
Subscribers: STL_MSFT, cfe-commits
Differential Revision: https://reviews.llvm.org/D31513
llvm-svn: 300116
|
|
|
|
|
|
|
|
| |
- also replace direct equality checks against the ConstantEvaluated enumerator with isConstantEvaluted(), in anticipation of adding finer granularity to the various ConstantEvaluated contexts and reinstating certain restrictions on where lambda expressions can occur in C++17.
- update the clang tablegen backend that uses these Enumerators, and add the relevant scope where needed.
llvm-svn: 299316
|
|
|
|
|
|
|
|
|
| |
Some clients (eg the cling interpreter) need to recover their parser from
errors.
Patch by Axel Naumann (D31190)!
llvm-svn: 298606
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
3.4.6 [basic.lookup.udir] paragraph 1:
In a using-directive or namespace-alias-definition, during the lookup for a namespace-name or for a name in a nested-name-specifier, only namespace names are considered.
Reviewers: rsmith, aaron.ballman
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D30848
llvm-svn: 298126
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and the nature of a declaration
This commit adds an external_source_symbol attribute to Clang. This attribute
specifies that a declaration originates from an external source and describes
the nature of that source. This attribute will be used to improve IDE features
like 'jump-to-definition' for mixed-language projects or project that use
auto-generated code.
rdar://30423368
Differential Revision: https://reviews.llvm.org/D29819
llvm-svn: 296649
|
|
|
|
|
|
|
|
| |
permits typedef union __attribute__((transparent_union)) {...}
Differential Revision: https://reviews.llvm.org/D28266
llvm-svn: 296518
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Previously Clang would simply ignore the 'template' keyword in this case.
llvm-svn: 294639
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
name. If the dependent name happened to end in a template-id (X<T>::Y<U>), we
would fail to notice that the 'typename' keyword is missing when resolving it
to a type.
It turns out that GCC has a similar bug. If this shows up in much real code, we
can easily downgrade this to an ExtWarn.
llvm-svn: 293815
|
|
|
|
| |
llvm-svn: 293355
|
|
|
|
|
|
| |
change intended.
llvm-svn: 293354
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change adds a new type node, DeducedTemplateSpecializationType, to
represent a type template name that has been used as a type. This is modeled
around AutoType, and shares a common base class for representing a deduced
placeholder type.
We allow deduced class template types in a few more places than the standard
does: in conditions and for-range-declarators, and in new-type-ids. This is
consistent with GCC and with discussion on the core reflector. This patch
does not yet support deduced class template types being named in typename
specifiers.
llvm-svn: 293207
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
We do not currently track the source locations for exception specifications such
that their source range can be queried through the AST. This leads to trying to
write more complex code to determine the source range for uses like FixItHints
(see D18575 for an example). In addition to use within tools like clang-tidy, I
think this information may become more important to track as exception
specifications become more integrated into the type system.
Patch by Don Hinton.
Reviewers: rsmith
Subscribers: malcolm.parsons, sbarzowski, alexfh, hintonda, cfe-commits
Differential Revision: https://reviews.llvm.org/D20428
llvm-svn: 291771
|
|
|
|
|
|
|
|
|
|
|
|
| |
This flag serves no purpose other than to prevent us walking through a type to
check whether it contains an 'auto' specifier; this duplication of information
is error-prone, does not appear to provide any performance benefit, and will
become less practical once we support C++1z deduced class template types and
eventually constrained types from the Concepts TS.
No functionality change intended.
llvm-svn: 291737
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change introduces UsingPackDecl as a marker for the set of UsingDecls
produced by pack expansion of a single (unresolved) using declaration. This is
not strictly necessary (we just need to be able to map from the original using
declaration to its expansions somehow), but it's useful to maintain the
invariant that each declaration reference instantiates to refer to one
declaration.
This is a re-commit of r290080 (reverted in r290092) with a fix for a
use-after-lifetime bug.
llvm-svn: 290203
|
|
|
|
|
|
|
| |
This reverts commit r290080 as it leads to many Clang crashes, e.g.:
http://lab.llvm.org:8011/builders/clang-cmake-aarch64-quick/builds/1814
llvm-svn: 290092
|
|
|
|
|
|
|
|
|
|
|
| |
This change introduces UsingPackDecl as a marker for the set of UsingDecls
produced by pack expansion of a single (unresolved) using declaration. This is
not strictly necessary (we just need to be able to map from the original using
declaration to its expansions somehow), but it's useful to maintain the
invariant that each declaration reference instantiates to refer to one
declaration.
llvm-svn: 290080
|
|
|
|
| |
llvm-svn: 289905
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We continue to support dynamic exception specifications in C++1z as an
extension, but produce an error-by-default warning when we encounter one. This
allows users to opt back into the feature with a warning flag, and implicitly
opts system headers back into the feature should they happen to use it.
There is one semantic change implied by P0003R5 but not implemented here:
violating a throw() exception specification should now call std::terminate
directly instead of calling std::unexpected(), but since P0003R5 also removes
std::unexpected() and std::set_unexpected, and the default unexpected handler
calls std::terminate(), a conforming C++1z program cannot tell that we are
still calling it. The upside of this strategy is perfect backwards
compatibility; the downside is that we don't get the more efficient 'noexcept'
codegen for 'throw()'.
llvm-svn: 289019
|
|
|
|
| |
llvm-svn: 287258
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This changes pointers to cached tokens for default arguments in C++ from raw pointers to unique_ptrs. There was a fixme in the code where the cached tokens are created about using a smart pointer.
The change is straightforward, though I did have to track down and fix a memory corruption caused by the change. memcpy was being used to copy parameter information. This duplicated the unique_ptr, which led to the cached token buffer being deleted prematurely.
Patch by David Tarditi!
Reviewers: malcolm.parsons
Subscribers: arphaman, malcolm.parsons, cfe-commits
Differential Revision: https://reviews.llvm.org/D26435
llvm-svn: 287241
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: aaron.ballman, mehdi_amini, dblaikie
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D26206
llvm-svn: 285799
|
|
|
|
|
|
|
| |
export-declarations. These don't yet have an effect on name visibility;
we still export everything by default.
llvm-svn: 280999
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some Windows SDK classes, for example
Windows::Storage::Streams::IBufferByteAccess, use the ATL way of spelling
attributes:
[uuid("....")] class IBufferByteAccess {};
To be able to use __uuidof() to grab the uuid off these types, clang needs to
support uuid as a Microsoft attribute. There was already code to skip Microsoft
attributes, extend that to look for uuid and parse it. Use the new "Microsoft"
attribute type added in r280575 (and r280574, r280576) for this.
Final part of https://reviews.llvm.org/D23895
llvm-svn: 280578
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There was already a function that moved attributes off the declspec into
an attribute list for attributes applying to the type, teach that function to
also move Microsoft attributes around and rename it to match its new broader
role.
Nothing uses Microsoft attributes yet, so no behavior change.
Part of https://reviews.llvm.org/D23895
llvm-svn: 280576
|
|
|
|
|
|
|
|
| |
into ParseDeclOrFunctionDefInternal() (which is called by
MaybeParseMicrosoftAttributes()), so that the attributes can be stored in
the DeclSpec. No behavior change yet, part of https://reviews.llvm.org/D23895
llvm-svn: 280574
|
|
|
|
| |
llvm-svn: 279558
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As reported in bug 28473, GCC supports "final" functionality in pre-C++11 code using the __final keyword. Clang currently supports the "final" keyword in accordance with the C++11 specification, however it ALSO supports it in pre-C++11 mode, with a warning.
This patch adds the "__final" keyword for compatibility with GCC in GCC Keywords mode (so it is enabled with existing flags), and issues a warning on its usage (suggesting switching to the C++11 keyword). This patch also adds a regression test for the functionality described. I believe this patch has minimal impact, as it simply adds a new keyword for existing behavior.
This has been validated with check-clang to avoid regressions. Patch is created in reference to revisions 276665.
Patch by Erich Keane.
Differential Revision: https://reviews.llvm.org/D22919
llvm-svn: 277134
|
|
|
|
|
|
| |
This is useful for source modification tools. There will be a follow-up commit using it.
llvm-svn: 275590
|