| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
http://reviews.llvm.org/D14134
llvm-svn: 253849
|
| |
|
|
|
|
| |
resolved by a call to yield_value / return_value before rejecting them.
llvm-svn: 253817
|
| |
|
|
| |
llvm-svn: 253816
|
| |
|
|
| |
llvm-svn: 253812
|
| |
|
|
|
|
| |
co_await and co_yield, and use it to hold await_* calls.
llvm-svn: 253811
|
| |
|
|
| |
llvm-svn: 253731
|
| |
|
|
| |
llvm-svn: 253725
|
| |
|
|
|
|
| |
unevaluated operands.
llvm-svn: 253641
|
| |
|
|
|
|
|
|
|
|
|
|
| |
ConstantEvaluated while substituting into non-type template argument defaults.
Also address a typo from a prior patch that performed a similar fix during Parsing of default non-type template arguments. I left the RAII ExpressionEvaluationContext variable Name as Unevaluated though we had switched the context to ConstantEvaluated.
There should be no functionality change here - since when expression evaluation context is popped off, for the most part these two contexts currently behave similarly in regards to lambda diagnostics and odr-use tracking.
Like its parsing counterpart, this patch presages the advent of constexpr lambda patches...
llvm-svn: 253590
|
| |
|
|
|
|
|
| |
Add support for vector mode attributes like "attribute((mode(V4SF)))". Also add warning about deprecated vector modes like GCC does.
Differential Revision: http://reviews.llvm.org/D14744
llvm-svn: 253551
|
| |
|
|
|
|
| |
std::coroutine_traits.
llvm-svn: 253535
|
| |
|
|
|
|
|
|
|
|
|
| |
driving a canonical difference between that and an unqualified
type is a really bad idea when both are valid. Instead, remember
that it was there in a non-canonical way, then look for that in
the one place we really care about it: block captures. The net
effect closely resembles the behavior of a decl attribute, except
still closely following ARC's standard qualifier parsing rules.
llvm-svn: 253534
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We created a malformed TemplateSpecializationType: it was dependent but
had a RecordType as it's canonical type. This would lead getAs to
crash. r249090 worked around this but we should fix this for real by
providing a more appropriate template specialization type as the
canonical type.
This fixes PR24246.
llvm-svn: 253495
|
| |
|
|
| |
llvm-svn: 253456
|
| |
|
|
|
|
|
|
| |
unsafe, since many operations on the types can trigger lazy deserialization of
more types and invalidate the iterators. This fixes a crasher, but I've not
been able to reduce it to a reasonable testcase yet.
llvm-svn: 253420
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, when there is a global register variable in a program that
is bound to an invalid register, clang/llvm prints an error message that
is not very user-friendly.
This commit improves the diagnostic and moves the check that used to be
in the backend to Sema. In addition, it makes changes to error out if
the size of the register doesn't match the declared variable size.
e.g., volatile register int B asm ("rbp");
rdar://problem/23084219
Differential Revision: http://reviews.llvm.org/D13834
llvm-svn: 253405
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
other than the top level, we issue an error. This breaks a fair amount of C++
code wrapping C libraries, where the C library is #included within a namespace
/ extern "C" combination, because the C library (probably) includes C++
standard library headers which may be within modules.
Without modules, this setup is harmless if (and *only* if) the corresponding
standard library module was already included outside the namespace, so
downgrade the error to a default-error extension in that case, so that it can
be selectively disabled for such misbehaving libraries.
llvm-svn: 253398
|
| |
|
|
|
|
| |
diagnostics. NFC
llvm-svn: 253316
|
| |
|
|
| |
llvm-svn: 253315
|
| |
|
|
| |
llvm-svn: 253314
|
| |
|
|
|
|
|
| |
declarations that are not simultaneously visible, and where at least one of
them has internal/no linkage.
llvm-svn: 253283
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
is_empty, is_polymorphic, and is_abstract didn't handle incomplete types
correctly. Only non-union class types must be complete for these
traits.
is_final and is_sealed don't care about the particular spelling of the
FinalAttr.
is_interface_class should always return false regardless of its input.
The type trait can only be satisfied in a mode we do not support (/CLR).
llvm-svn: 253184
|
| |
|
|
|
|
| |
on the AST context instead of Preprocessor. NFC
llvm-svn: 253175
|
| |
|
|
| |
llvm-svn: 253174
|
| |
|
|
| |
llvm-svn: 253173
|
| |
|
|
|
|
|
|
| |
This makes TypeAliasTemplateDecl accessible via LibClang and python bindings
Differential Revision: http://reviews.llvm.org/D13844
llvm-svn: 253166
|
| |
|
|
|
|
| |
DiagnosticsEngine and Preprocessor. Everything the preprocessor was being used for can be acquired from Sema.
llvm-svn: 253158
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Clang tries to figure out if a call to abs is suspicious by looking
through implicit casts to look at the underlying, implicitly converted
type.
Interestingly, C has implicit conversions from pointer-ish types like
function to less exciting types like int. This trips up our 'abs'
checker because it doesn't know which variant of 'abs' is appropriate.
Instead, diagnose 'abs' called on function types upfront. This sort of
thing is highly suspicious and is likely indicative of a missing
pointer dereference/function call/array index operation.
This fixes PR25532.
llvm-svn: 253156
|
| |
|
|
| |
llvm-svn: 253155
|
| |
|
|
|
|
| |
ParserDiagnostic.h diagnostics.
llvm-svn: 253143
|
| |
|
|
| |
llvm-svn: 253142
|
| |
|
|
| |
llvm-svn: 253136
|
| |
|
|
|
|
|
|
|
| |
r233345 started being stricter about typedef names for linkage purposes
in non-visible modules, but broke languages without the ODR.
rdar://23527954
llvm-svn: 253123
|
| |
|
|
|
|
|
|
| |
While functions types are complete, they cannot be constructed.
This fixes PR25513.
llvm-svn: 253013
|
| |
|
|
|
|
|
|
|
| |
the linkage of the enumeration. For enumerators of unnamed enumerations, extend
the -Wmodules-ambiguous-internal-linkage extension to allow selecting an
arbitrary enumerator (but only if they all have the same value, otherwise it's
ambiguous).
llvm-svn: 253010
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The ``disable_tail_calls`` attribute instructs the backend to not
perform tail call optimization inside the marked function.
For example,
int callee(int);
int foo(int a) __attribute__((disable_tail_calls)) {
return callee(a); // This call is not tail-call optimized.
}
Note that this attribute is different from 'not_tail_called', which
prevents tail-call optimization to the marked function.
rdar://problem/8973573
Differential Revision: http://reviews.llvm.org/D12547
llvm-svn: 252986
|
| |
|
|
| |
llvm-svn: 252971
|
| |
|
|
|
|
| |
due to ambiguity.
llvm-svn: 252967
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
declarations in redeclaration lookup. A declaration is now visible to
lookup if:
* It is visible (not in a module, or in an imported module), or
* We're doing redeclaration lookup and it's externally-visible, or
* We're doing typo correction and looking for unimported decls.
We now support multiple modules having different internal-linkage or no-linkage
definitions of the same name for all entities, not just for functions,
variables, and some typedefs. As previously, if multiple such entities are
visible, any attempt to use them will result in an ambiguity error.
This patch fixes the linkage calculation for a number of entities where we
previously didn't need to get it right (using-declarations, namespace aliases,
and so on). It also classifies enumerators as always having no linkage, which
is a slight deviation from the C++ standard's definition, but not an observable
change outside modules (this change is being discussed on the -core reflector
currently).
This also removes the prior special case for tag lookup, which made some cases
of this work, but also led to bizarre, bogus "must use 'struct' to refer to type
'Foo' in this scope" diagnostics in C++.
llvm-svn: 252960
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
DR407, the C++ standard doesn't really say how this should work. Here's what we
do (which is consistent with DR407 as far as I can tell):
* When performing name lookup for an elaborated-type-specifier, a tag
declaration hides a typedef declaration that names the same type.
* When performing any other kind of lookup, a typedef declaration hides
a tag declaration that names the same type.
In any other case where lookup finds both a typedef and a tag (that is, when
they name different types), the lookup will be ambiguous. If lookup finds a
tag and a typedef that name the same type, and finds anything else, the lookup
will always be ambiguous (even if the other entity would hide the tag, it does
not also hide the typedef).
llvm-svn: 252959
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This failed to solve the problem it was aimed at, and introduced just as many
issues as it resolved. Realistically, we need to deal with the possibility that
multiple modules might define different internal linkage symbols with the same
name, and this isn't a problem unless two such symbols are simultaneously
visible.
The case where two modules define equivalent internal linkage symbols is
handled by r252063: if lookup finds multiple sufficiently-similar entities from
different modules, we just pick one of them as an extension (but we keep them
separate).
llvm-svn: 252957
|
| |
|
|
| |
llvm-svn: 252855
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: Diagnose when a function concept declaration has parameter(s)
Reviewers: rsmith, faisalv, aaron.ballman, hubert.reinterpretcast
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D14352
llvm-svn: 252827
|
| |
|
|
| |
llvm-svn: 252793
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
https://gcc.gnu.org/onlinedocs/gcc/Typeof.html
Differences from the GCC extension:
* __auto_type is also permitted in C++ (but only in places where
it could appear in C), allowing its use in headers that might
be shared across C and C++, or used from C++98
* __auto_type can be combined with a declarator, as with C++ auto
(for instance, "__auto_type *p")
* multiple variables can be declared in a single __auto_type
declaration, with the C++ semantics (the deduced type must be
the same in each case)
This patch also adds a missing restriction on applying typeof to
a bit-field, which GCC has historically rejected in C (due to
lack of clarity as to whether the operand should be promoted).
The same restriction also applies to __auto_type in C (in both
GCC and Clang).
This also fixes PR25449.
Patch by Nicholas Allegra!
llvm-svn: 252690
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
std::initializer_list<T> type. Instead, the list must contain a single element
and the type is deduced from that.
In Clang 3.7, we warned by default on all the cases that would change meaning
due to this change. In Clang 3.8, we will support only the new rules -- per
the request in N3922, this change is applied as a Defect Report against earlier
versions of the C++ standard.
This change is not entirely trivial, because for lambda init-captures we
previously did not track the difference between direct-list-initialization and
copy-list-initialization. The difference was not previously observable, because
the two forms of initialization always did the same thing (the elements of the
initializer list were always copy-initialized regardless of the initialization
style used for the init-capture).
llvm-svn: 252688
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The attrubite is applicable to functions and variables and changes
the linkage of the subject to internal.
This is the same functionality as C-style "static", but applicable to
class methods; and the same as anonymouns namespaces, but can apply
to individual methods of a class.
Following the proposal in
http://lists.llvm.org/pipermail/cfe-dev/2015-October/045580.html
llvm-svn: 252648
|
| |
|
|
| |
llvm-svn: 252399
|
| |
|
|
| |
llvm-svn: 252398
|
| |
|
|
| |
llvm-svn: 252397
|