| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: When merging definitions with ModulesLocalVisibility enabled it's important to make deleted definitions implicitly inline, otherwise they'll be diagnosed as a redefinition.
Reviewers: silvas, manmanren, rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D26143
llvm-svn: 285655
|
|
|
|
|
|
|
| |
implicitly deleted and overrides a non-deleted function, explain why the
function is deleted. For PR30844.
llvm-svn: 285610
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If two modules contain duplicate class definitions the lookup result can contain
more than 2 elements. Sift the lookup results until we find a field decl.
It is not necessary to do ODR checks in place as they done elsewhere.
This should fix issues when compiling with libstdc++ 5.2 and 6.2.
Patch developed in collaboration with Richard Smith!
llvm-svn: 285184
|
|
|
|
|
|
|
|
|
|
|
| |
we don't collapse that down to a single entry if it's not a redeclaration.
Instead, set the Redeclaration bit on the Declarator to indicate whether a
function is a redeclaration (which may not have been linked into the
redeclaration chain if it's a dependent context friend).
Fixes a rejects-valid; see testcase.
llvm-svn: 284802
|
|
|
|
|
|
| |
struct with unnamed bitfields.
llvm-svn: 284761
|
|
|
|
|
|
|
| |
implements the bulk of the change (modifying the type system to include
exception specifications), but not all the details just yet.
llvm-svn: 284337
|
|
|
|
|
|
|
|
|
| |
Although the itanium environment uses the itanium layout for C++, treat the
dllexport semantics more similarly to the MSVC specification. This preserves
the existing behaviour for the use of the itanium ABI on non-windows-itanium
environments. Export the inline definitions too.
llvm-svn: 284288
|
|
|
|
|
|
|
|
|
|
|
| |
past-the-end iterator.
Original commit message:
P0035R4: Semantic analysis and code generation for C++17 overaligned
allocation.
llvm-svn: 283789
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Once a base class has been made invalid (by a static_assert for example) all using-member declarations in the derived classes will result in a "not a base class" diagnostic. This diagnostic is very misleading and should not be emitted.
This change is needed to help libc++ produce reasonable diagnostics in `std::optional` and `std::variant`.
Reviewers: rsmith, majnemer, aaron.ballman
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D25430
llvm-svn: 283755
|
|
|
|
|
|
|
|
|
|
|
|
| |
allocation."
This reverts commit r283722. Breaks:
Clang.SemaCUDA.device-var-init.cu
Clang.CodeGenCUDA.device-var-init.cu
http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-expensive/884/
llvm-svn: 283750
|
|
|
|
|
|
| |
allocation.
llvm-svn: 283722
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously if a file-level function was defined inside befriending
template class, it always was treated as defined. For instance, the code like:
```
int func(int x);
template<typename T> class C1 {
friend int func(int x) { return x; }
};
template<typename T> class C2 {
friend int func(int x) { return x; }
};
```
could not be compiled due to function redefinition, although not of the templates
is instantiated. Moreover, the body of friend function can contain use of template
parameters, attempt to get definition of such function outside any instantiation
causes compiler abnormal termination.
Other compilers (gcc, icc) follow viewpoint that the body of the function defined
in friend declaration becomes available when corresponding class is instantiated.
This patch implements this viewpoint in clang.
Definitions introduced by friend declarations in template classes are not added
to the redeclaration chain of corresponding function. Only when the template is
instantiated, instantiation of the function definition is placed to the chain.
The fix was made in collaboration with Richard Smith.
This change fixes PR8035, PR17923, PR22307 and PR25848.
Differential Revision: http://reviews.llvm.org/D16989
llvm-svn: 283207
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Look for coroutine_traits and friends in std::experimental namespace.
Patch (mostly) by EricWF.
Reviewers: cfe-commits, EricWF, rsmith
Subscribers: majnemer, mehdi_amini
Differential Revision: https://reviews.llvm.org/D25068
llvm-svn: 283170
|
|
|
|
|
|
|
| |
just warn that the second declaration is missing the 'inline' keyword. This is
valid, and we shouldn't be suggesting otherwise.
llvm-svn: 282981
|
|
|
|
| |
llvm-svn: 282800
|
|
|
|
| |
llvm-svn: 282555
|
|
|
|
|
|
|
|
|
|
| |
In some cases, non-special member functions were being marked as being defaulted
in templated classes. This can cause interactions with later code that expects
the default function to be one of the specific member functions. Fix the check
so that templated class members are checked the same way as non-templated class
members are.
llvm-svn: 282547
|
|
|
|
|
|
|
|
| |
indirect virtual bases. We don't need to be able to invoke such an assignment
operator from the derived class, and we shouldn't delete the derived assignment
op if we can't do so.
llvm-svn: 280288
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Some function calls in CUDA are allowed to appear in
semantically-correct programs but are an error if they're ever
codegen'ed. Specifically, a host+device function may call a host
function, but it's an error if such a function is ever codegen'ed in
device mode (and vice versa).
Previously, clang made no attempt to catch these errors. For the most
part, they would be caught by ptxas, and reported as "call to unknown
function 'foo'".
Now we catch these errors and report them the same as we report other
illegal calls (e.g. a call from a host function to a device function).
This has a small change in error-message behavior for calls that were
previously disallowed (e.g. calls from a host to a device function).
Previously, we'd catch disallowed calls fairly early, before doing
additional semantic checking e.g. of the call's arguments. Now we catch
these illegal calls at the very end of our semantic checks, so we'll
only emit a "illegal CUDA call" error if the call is otherwise
well-formed.
Reviewers: tra, rnk
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D23242
llvm-svn: 278759
|
|
|
|
| |
llvm-svn: 278642
|
|
|
|
|
|
|
|
| |
tuple-like decomposition declaration. This significantly simplifies the
semantics of BindingDecls for AST consumers (they can now always be evalated
at the point of use).
llvm-svn: 278640
|
|
|
|
| |
llvm-svn: 278458
|
|
|
|
| |
llvm-svn: 278448
|
|
|
|
| |
llvm-svn: 278447
|
|
|
|
|
|
|
| |
decomposition declaration for arrays, aggregate-like structs, tuple-like
types, and (as an extension) for complex and vector types.
llvm-svn: 278435
|
|
|
|
|
|
|
|
|
|
|
| |
decomposition declarations.
There are a couple of things in the wording that seem strange here:
decomposition declarations are permitted at namespace scope (which we partially
support here) and they are permitted as the declaration in a template (which we
reject).
llvm-svn: 276492
|
|
|
|
|
|
|
|
|
|
| |
Summary: Removed unused headers, replaced some headers with forward class declarations
Patch by: Eugene <claprix@yandex.ru>
Differential Revision: https://reviews.llvm.org/D20100
llvm-svn: 275882
|
|
|
|
|
|
|
|
| |
they're redeclarations. This is necessary in order for name lookup to correctly
find the most recent declaration of the name (which affects default template
argument lookup and cross-module merging, among other things).
llvm-svn: 275612
|
|
|
|
|
|
|
|
| |
ArrayRef is a little better than passing around a pointer/length pair.
No functional change is intended.
llvm-svn: 274601
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
instantiations"
Reverts r273305 and re-instates r273296.
We needed to fix a bug in Sema::MarkVTableUsed to ensure that operator
delete lookup occurs when the vtable is referenced. We already had a
special case to look up operator delete when dllimport was used, but I
think should really mark virtual destructors referenced any time the
vtable is used.
llvm-svn: 274147
|
|
|
|
|
|
|
|
| |
constructor would be; this is effectively required by P0136R1. This has the
effect of exposing the validity of the base class initialization steps to
SFINAE checks.
llvm-svn: 274088
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Replace inheriting constructors implementation with new approach, voted into
C++ last year as a DR against C++11.
Instead of synthesizing a set of derived class constructors for each inherited
base class constructor, we make the constructors of the base class visible to
constructor lookup in the derived class, using the normal rules for
using-declarations.
For constructors, UsingShadowDecl now has a ConstructorUsingShadowDecl derived
class that tracks the requisite additional information. We create shadow
constructors (not found by name lookup) in the derived class to model the
actual initialization, and have a new expression node,
CXXInheritedCtorInitExpr, to model the initialization of a base class from such
a constructor. (This initialization is special because it performs real perfect
forwarding of arguments.)
In cases where argument forwarding is not possible (for inalloca calls,
variadic calls, and calls with callee parameter cleanup), the shadow inheriting
constructor is not emitted and instead we directly emit the initialization code
into the caller of the inherited constructor.
Note that this new model is not perfectly compatible with the old model in some
corner cases. In particular:
* if B inherits a private constructor from A, and C uses that constructor to
construct a B, then we previously required that A befriends B and B
befriends C, but the new rules require A to befriend C directly, and
* if a derived class has its own constructors (and so its implicit default
constructor is suppressed), it may still inherit a default constructor from
a base class
llvm-svn: 274049
|
|
|
|
|
|
|
| |
variable weak discardable linkage and partially-ordered initialization, and is
implied for constexpr static data members.)
llvm-svn: 273754
|
|
|
|
|
|
| |
No functional change is intended, just a small refactoring.
llvm-svn: 273647
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-Wfor-loop-analysis warnings for a for-loop with a condition variable. In such
a case, the loop condition variable is modified on each iteration of the loop
by definition.
Original commit message:
Rearrange condition handling so that semantic checks on a condition variable
are performed before the other substatements of the construct are parsed,
rather than deferring them until the end. This allows better error recovery
from semantic errors in the condition, improves diagnostic order, and is a
prerequisite for C++17 constexpr if.
llvm-svn: 273600
|
|
|
|
|
|
|
|
| |
condition variable"
as it caused a regression in -Wfor-loop-analysis.
llvm-svn: 273589
|
|
|
|
|
|
|
|
|
| |
are performed before the other substatements of the construct are parsed,
rather than deferring them until the end. This allows better error recovery
from semantic errors in the condition, improves diagnostic order, and is a
prerequisite for C++17 constexpr if.
llvm-svn: 273548
|
|
|
|
| |
llvm-svn: 272415
|
|
|
|
| |
llvm-svn: 272357
|
|
|
|
|
|
|
|
| |
Variably modified types shouldn't be permitted in catch clauses.
This fixes PR28047.
llvm-svn: 272159
|
|
|
|
|
|
|
|
|
|
|
| |
In case of template instantiations query the template instantiation pattern,
which had actually '=default'.
Fixes https://llvm.org/bugs/show_bug.cgi?id=27739
Patch reviewed by Richard Smith.
llvm-svn: 270553
|
|
|
|
|
|
|
|
|
|
|
|
| |
Clang doesn't dllexport defaulted special member function defaulted
inside class but does it if they defaulted outside class. MSVC doesn't
make any distinction where they were defaulted. Also MSVC 2013 and 2015
export different set of members. MSVC2015 doesn't emit trivial defaulted
x-tors but does emit copy assign operator.
Differential revision: http://reviews.llvm.org/D20422
llvm-svn: 270535
|
|
|
|
|
|
| |
UsingDecl (so that redeclaration lookup can find it).
llvm-svn: 269530
|
|
|
|
|
|
|
| |
implicit copy constructor/assignment, and other minor cleanups. No
functionality change intended.
llvm-svn: 269457
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
account MSVC compatibility version
Clang creates implicit move constructor/assign operator in all cases if
there is std=c++11. But MSVC supports such generation starting from
version 1900 only. As result we have some binary incompatibility.
Differential Revision: http://reviews.llvm.org/D19156
Patch by Andrew V. Tischenko
llvm-svn: 269400
|
|
|
|
|
|
|
|
|
| |
a base class via a using-declaration. If a class has a using-declaration
declaring either a constructor or an assignment operator, eagerly declare its
special members in case they need to displace a shadow declaration from a
using-declaration.
llvm-svn: 269398
|
|
|
|
|
|
|
|
|
| |
This is in preparation for C++ P0136R1, which switches the model for inheriting
constructors over from synthesizing a constructor to finding base class
constructors (via using shadow decls) when looking for derived class
constructors.
llvm-svn: 269231
|
|
|
|
|
|
| |
using-declaration that names a class-scope enumerator.
llvm-svn: 268664
|
|
|
|
|
|
|
|
|
|
|
| |
enumerators:
* an unscoped enumerator whose enumeration is a class member is itself a class
member, so can only be the subject of a class-scope using-declaration.
* a scoped enumerator cannot be the subject of a class-scope using-declaration.
llvm-svn: 268594
|
|
|
|
|
|
|
|
|
|
|
| |
Fix crash in BuildCXXDefaultInitExpr when member of template class has
same name as the class itself.
Based on patch by Raphael "Teemperor" Isemann!
Differential Revision: http://reviews.llvm.org/D19721
llvm-svn: 268082
|