| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
An optional nopartial can be placed after the platform name.
int bar() __attribute__((availability(macosx,nopartial,introduced=10.12))
When deploying back to a platform version prior to when the declaration was
introduced, with 'nopartial', Clang emits an error specifying that the function
is not introduced yet; without 'nopartial', the behavior stays the same: the
declaration is `weakly linked`.
A member is added to the end of AttributeList to save the location of the
'nopartial' keyword. A bool member is added to AvailabilityAttr.
The diagnostics for 'nopartial' not-yet-introduced is handled in the same way as
we handle unavailable cases.
Reviewed by Doug Gregor and Jordan Rose.
rdar://23791325
llvm-svn: 261163
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
thousands of modules, each of which declares the same namespace, linearly
scanning the redecl chain looking for a visible declaration (once for each leaf
module, for each use) performs very poorly. Namespace visibility can only
decrease when we leave a module during a module build step, and we never care
*which* visible declaration of a namespace we find, so we can cache this very
effectively.
This results in a 35x speedup on one of our internal build steps (2m -> 3.5s),
but is hard to unit test because it requires a very large number of modules.
Ideas for a test appreciated! No functionality change intended other than the
speedup.
llvm-svn: 261161
|
|
|
|
|
|
|
|
| |
minor fixes.
Differential revision: http://reviews.llvm.org/D17218
llvm-svn: 260757
|
|
|
|
|
|
| |
because the information is now stored in TemplateDecl.
llvm-svn: 260155
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
diagnosing when 'concept' is specified on a function or template
specialization.
Since a concept can only be applied to a function or variable template,
the concept bit is stored in TemplateDecl as a PointerIntPair.
Reviewers: rsmith, faisalv, aaron.ballman, hubert.reinterpretcast
Differential Revision: http://reviews.llvm.org/D13357
llvm-svn: 260074
|
|
|
|
|
|
|
|
|
|
| |
When building a PCH with modules enabled this import would assert in the
ASTWriter and (if assertions were disabled) sometimes crash the compiler
that loaded the resulting PCH when trying to lookup the submodule ID.
rdar://problem/24137448
llvm-svn: 259859
|
|
|
|
|
|
|
|
| |
C++14 generic lambdas. It conflicts with the C++14 return type deduction
mechanism, and results in us failing to actually deduce the lambda's return
type in some cases.
llvm-svn: 259609
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In general CUDA does not allow dynamic initialization of
global device-side variables. One exception is that CUDA allows
records with empty constructors as described in section E2.2.1 of
CUDA 7.5 Programming guide.
This patch applies initializer checks for all device-side variables.
Empty constructors are accepted, but no code is generated for them.
Differential Revision: http://reviews.llvm.org/D15305
llvm-svn: 259592
|
|
|
|
|
|
|
|
|
|
|
| |
for-range expression.
Fix the issue discovered by fuzzing (PR23057, comment 18) by handling nullptr in Sema::ActOnCXXForRangeDecl
and correct delayed typos in for-range expression before calling Sema::ActOnCXXForRangeStmt. Also fixes PR26288.
Differential Revision: http://reviews.llvm.org/D16630
llvm-svn: 259532
|
|
|
|
|
|
|
|
|
|
|
| |
Diagnose if the return type of a function concept or declaration type of a
variable concept is not bool.
Reviewers: hubert.reinterpretcast
Differential Revision: http://reviews.llvm.org/D16163
llvm-svn: 259159
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For
void f() {
union { int i; };
}
clang used to omit the RecordDecl from the anonymous union from the AST.
That's because the code creating it only called PushOnScopeChains(), which adds
it to the current DeclContext, which here is the function's DeclContext. But
RecursiveASTVisitor doesn't descent into all decls in a FunctionDecl.
Instead, for DeclContexts that contain statements, return the RecordDecl so
that it can be included in the DeclStmt containing the VarDecl for the union.
Interesting bits from the AST before this change:
|-FunctionDecl
| `-CompoundStmt
| |-DeclStmt
| | `-VarDecl 0x589cd60 <col:3> col:3 implicit used 'union (anonymous at test.cc:3:3)' callinit
After this change:
-FunctionDecl
| `-CompoundStmt
| |-DeclStmt
| | |-CXXRecordDecl 0x4612e48 <col:3, col:18> col:3 union definition
| | | |-FieldDecl 0x4612f70 <col:11, col:15> col:15 referenced i 'int'
| | `-VarDecl 0x4613010 <col:3> col:3 implicit used 'union (anonymous at test.cc:3:3)' callinit
This is now closer to how anonymous struct and unions are represented as
members of structs. It also enabled deleting some one-off code in the
template instantiation code.
Finally, it fixes a crash with ASTMatchers, see the included test case
(this fixes http://crbug.com/580749).
llvm-svn: 259079
|
|
|
|
| |
llvm-svn: 259077
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Member pointers in the MS ABI are tricky for a variety of reasons.
The size of a member pointer is indeterminate until the program reaches
a point where the representation is required to be known. However,
*pointers* to member pointers may exist without knowing the pointee
type's representation. In these cases, we synthesize an opaque LLVM
type for the pointee type.
However, we can be in a situation where the underlying member pointer's
representation became known mid-way through the program. To account for
this, we attempted to manicure CodeGen's type-cache so that we can
replace the opaque member pointer type with the real deal while leaving
the pointer types unperturbed. This, unfortunately, is a problematic
approach to take as we will violate CodeGen's invariants.
These violations are mostly harmless but let's do the right thing
instead: invalidate the type-cache if a member pointer's LLVM
representation changes.
This fixes PR26313.
llvm-svn: 258839
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Turns out the variadic function checking added in r258643 was too strict
for some existing users; give them an escape valve. When
-fcuda-allow-variadic-functions is passed, the front-end makes no
attempt to disallow C-style variadic functions. Calls to va_arg are
still not allowed.
Reviewers: tra
Subscribers: cfe-commits, jhen, echristo, bkramer
Differential Revision: http://reviews.llvm.org/D16559
llvm-svn: 258822
|
|
|
|
|
|
|
|
|
|
|
| |
__GetExceptionInfo triggered Sema::LazilyCreateBuiltin which tries to
create a non-templated function decl. This is unnecessary and
ill-advised, there is no need for us to create a declaration for such a
builtin.
This fixes PR26298.
llvm-svn: 258762
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: tra
Subscribers: cfe-commits, echristo, jhen
Differential Revision: http://reviews.llvm.org/D16484
llvm-svn: 258643
|
|
|
|
| |
llvm-svn: 257958
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
redeclares an existing tag but are creating a new declaration anyway (because
it has attributes or changes the visibility of the name), don't warn that it
won't be visible outside the current scope. That's not true.
Also narrow down the set of cases where we create these extra declarations when
building modules; previously, all tag declarations but the first in a module
header would get this treatment if -fmodules-local-submodule-visibility. (This
isn't a functional change, but we try to avoid creating these extra
declarations whenever we can.)
llvm-svn: 257403
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Support for OpenCL 2.0 pipe type.
This is a bug-fix version for bader's patch reviews.llvm.org/D14441
Reviewers: pekka.jaaskelainen, Anastasia
Subscribers: bader, Anastasia, cfe-commits
Differential Revision: http://reviews.llvm.org/D15603
llvm-svn: 257254
|
|
|
|
|
|
|
|
| |
tag (because the previous declaration was found in a different module), inject
the tag into the appropriate scope (that is, the enclosing scope if we're in a
function prototype scope in C++).
llvm-svn: 257251
|
|
|
|
|
|
| |
union member is declared first and the tag name is declared second.
llvm-svn: 256979
|
|
|
|
|
|
|
| |
elaborated-type-specifier, create a declaration of it to track that the current
module makes it visible too.
llvm-svn: 256907
|
|
|
|
|
|
| |
prototype scope in a function definition.
llvm-svn: 256803
|
|
|
|
| |
llvm-svn: 256576
|
|
|
|
|
|
|
|
|
|
| |
underlying decls. Preserve the found declaration throughout, and only map to
the underlying declaration when we want to check whether it's the right kind.
This allows us to provide the right source location for the found declaration,
and prepares for the possibility of underlying decls with a different name
from the found decl.
llvm-svn: 256575
|
|
|
|
|
|
|
|
|
| |
have a nested name specifier. Strictly speaking, forward declarations of class
template partial specializations are not permitted at all, but that seems like
an obvious wording defect, and if we allow them without a nested name specifier
we should also allow them with a nested name specifier.
llvm-svn: 255383
|
|
|
|
|
|
|
|
|
| |
a hidden tag"
Now not trying to use a C++ lookup mechanism in C (d'oh). Unqualified
lookup is actually fine for this case in C.
llvm-svn: 255377
|
|
|
|
|
|
| |
asm label after the first ODR-use. Detects problems like the one in PR22830 where gcc and clang both compiled the file but with different behaviour.
llvm-svn: 255371
|
|
|
|
|
|
|
|
|
|
| |
a hidden tag"
This is causing assertion failures; reverting until I can fix.
This reverts commit r255267
llvm-svn: 255324
|
|
|
|
|
|
|
|
|
| |
This makes non-C++ languages find the same decl as C++ does to
workaround a regression introduced in r252960.
rdar://problem/23784203
llvm-svn: 255267
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`pass_object_size` is our way of enabling `__builtin_object_size` to
produce high quality results without requiring inlining to happen
everywhere.
A link to the design doc for this attribute is available at the
Differential review link below.
Differential Revision: http://reviews.llvm.org/D13263
llvm-svn: 254554
|
|
|
|
|
|
|
| |
We will still allow it in system headers, in macros from system headers, when
combined with an 'asm' label, and under the flag -Wno-register.
llvm-svn: 254097
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
declarations that are not simultaneously visible, and where at least one of
them has internal/no linkage.
llvm-svn: 253283
|
|
|
|
|
|
| |
ParserDiagnostic.h diagnostics.
llvm-svn: 253143
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This attribute is used to prevent tail-call optimizations to the marked
function. For example, in the following piece of code, foo1 will not be
tail-call optimized:
int __attribute__((not_tail_called)) foo1(int);
int foo2(int a) {
return foo1(a); // Tail-call optimization is not performed.
}
The attribute has effect only on statically bound calls. It has no
effect on indirect calls. Also, virtual functions and objective-c
methods cannot be marked as 'not_tail_called'.
rdar://problem/22667622
Differential Revision: http://reviews.llvm.org/D12922
llvm-svn: 252369
|
|
|
|
| |
llvm-svn: 252125
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Diagnose when the 'concept' specifier is used on a typedef or function parameter.
Reviewers: rsmith, hubert.reinterpretcast, aaron.ballman, faisalv
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D14316
llvm-svn: 252061
|