| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
| |
minor fixes (NFC).
llvm-svn: 318570
|
| |
|
|
|
|
| |
llvm-clang-x86_64-expensive-checks-win (NFC).
llvm-svn: 318538
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
explicitly instantiated, still emit it with each use.
We don't emit a definition of the member with an explicit instantiation
definition (and indeed it appears that we're not allowed to, since an explicit
instantiation definition does not constitute an odr-use and only odr-use
permits definition for defaulted special members). So we still need to emit a
weak definition with each use.
This also makes defaulted-in-class declarations behave more like
implicitly-declared special members, which matches their design intent.
And it matches the way this problem was solved in GCC.
llvm-svn: 318474
|
| |
|
|
|
|
|
|
| |
Patch by Nikolai Kosjar!
Differential Revision: https://reviews.llvm.org/D40066
llvm-svn: 318367
|
| |
|
|
|
|
|
|
| |
Patch by Nikolai Kosjar!
Differential Revision: https://reviews.llvm.org/D39957
llvm-svn: 318365
|
| |
|
|
|
|
| |
other minor fixes (NFC).
llvm-svn: 318341
|
| |
|
|
|
|
| |
but invalid designator.
llvm-svn: 318258
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When we merge together class definitions, we can end up with the canonical
declaration of a field not being the one that was lexically within the
canonical definition of the class. Additionally, when we merge class
definitions via update records (eg, for a template specialization whose
declaration is instantiated in one module and whose definition is instantiated
in multiple others), we can end up with the list of lexical contents for the
class not including a particular declaration of a field whose lexical parent is
that class definition. In the worst case, we have a field whose canonical
declaration's lexical parent has no fields, and in that case this attempt to
number the fields by walking the fields in the declaration of the class that
contained one of the canonical fields will fail.
Instead, when numbering fields in a class, do the obvious thing: walk the
fields in the definition.
I'm still trying to reduce a testcase; the setup that leads to the above
scenario seems to be quite fragile.
llvm-svn: 318245
|
| |
|
|
|
|
| |
minor fixes (NFC).
llvm-svn: 318221
|
| |
|
|
|
|
| |
minor fixes (NFC).
llvm-svn: 318216
|
| |
|
|
|
|
|
|
| |
Patch by: Zoltan Gera!
Differential Revision: https://reviews.llvm.org/D39247
llvm-svn: 318147
|
| |
|
|
|
|
| |
minor fixes (NFC).
llvm-svn: 318101
|
| |
|
|
|
|
|
|
| |
From http://reviews.llvm.org/D4368 these cases were thought to not be reachable
and the checks removed before the rest of the code was committed in r216649.
However, these cases are reachable and the checks are added back.
llvm-svn: 317957
|
| |
|
|
|
|
| |
minor fixes (NFC).
llvm-svn: 317854
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
For code reuse in SemaCodeComplete.
Note that the tests for QualTypeNames are still in Tooling as they use
Tooling's common testing code.
Reviewers: rsmith, saugustine, rnk, klimek, bkramer
Reviewed By: rnk
Subscribers: cfe-commits, mgorny
Differential Revision: https://reviews.llvm.org/D39224
llvm-svn: 317676
|
| |
|
|
|
|
| |
minor fixes (NFC).
llvm-svn: 317644
|
| |
|
|
|
|
|
|
|
|
|
| |
Added support for regcall as default calling convention. Also added code to
exclude main when applying default calling conventions.
Patch-By: eandrews
Differential Revision: https://reviews.llvm.org/D39210
llvm-svn: 317268
|
| |
|
|
| |
llvm-svn: 317052
|
| |
|
|
|
|
|
|
|
|
|
|
| |
name the same namespace.
They might have different visibility, and thus discarding all but one of them
can result in rejecting valid code. Also fix name lookup to cope with multiple
using-directives being found that denote the same namespace, where some are not
visible -- don't cache an "already visited" state for a using-directive that we
didn't visit because it was hidden.
llvm-svn: 316965
|
| |
|
|
|
|
|
|
| |
This will be useful for certain refactoring actions.
rdar://34202062
llvm-svn: 316631
|
| |
|
|
|
|
|
|
|
|
|
| |
Fastcall doesn't support variadic function calls, so
setting the default calling convention to Fastcall would
result in incorrect code being emitted for these conditions.
This patch adds a 'variadic' test to the default calling conv
test, as well as fixes the behavior of fastcall.
llvm-svn: 316528
|
| |
|
|
| |
llvm-svn: 316521
|
| |
|
|
|
|
|
|
|
|
|
|
| |
A helper builtin to facilitate implementing the
std::has_unique_object_representations type trait.
Requested here: https://bugs.llvm.org/show_bug.cgi?id=34942
Also already exists in GCC and MSVC.
Differential Revision: https://reviews.llvm.org/D39064
llvm-svn: 316518
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
C++14 [dcl.constexpr]p4 states that in the body of a constexpr
constructor,
> every non-variant non-static data member and base class sub-object
shall be initialized
However, [class.bit]p2 notes that
> Unnamed bit-fields are not members and cannot be initialized.
Therefore, we should make sure to filter them out of the check that
all fields are initialized.
Fixing this makes the constant evaluator a bit smarter, and
specifically allows constexpr constructors to avoid tripping
-Wglobal-constructors when the type contains unnamed bitfields.
Reviewed at https://reviews.llvm.org/D39035.
llvm-svn: 316408
|
| |
|
|
|
|
|
| |
of a static constexpr data member if it's defined 'constexpr' out of line, not
only if it's defined 'constexpr' in the class.
llvm-svn: 316310
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
constant expressions.
We permit array-to-pointer decay on such arrays, but disallow pointer
arithmetic (since we do not know whether it will have defined behavior).
This is based on r311970 and r301822 (the former by me and the latter by Robert
Haberlach). Between then and now, two things have changed: we have committee
feedback indicating that this is indeed the right direction, and the code
broken by this change has been fixed.
This is necessary in C++17 to continue accepting certain forms of non-type
template argument involving arrays of unknown bound.
llvm-svn: 316245
|
| |
|
|
|
|
|
|
|
|
| |
As reported here https://bugs.llvm.org/show_bug.cgi?id=34988
[[nodiscard]] warnings were not being suppressed for
volatile-ref return values.
Differential Revision: https://reviews.llvm.org/D39075
llvm-svn: 316166
|
| |
|
|
|
|
|
|
| |
Patch by: Rafael Stahl!
Differential Revision: https://reviews.llvm.org/D38943
llvm-svn: 316069
|
| |
|
|
|
|
| |
double square bracket attributes in C code.
llvm-svn: 316026
|
| |
|
|
|
|
|
|
| |
This allows to return the static value that we know at compile time.
Differential Revision: https://reviews.llvm.org/D38968
llvm-svn: 316001
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Convert clang::LangAS to a strongly typed enum
Currently both clang AST address spaces and target specific address spaces
are represented as unsigned which can lead to subtle errors if the wrong
type is passed. It is especially confusing in the CodeGen files as it is
not possible to see what kind of address space should be passed to a
function without looking at the implementation.
I originally made this change for our LLVM fork for the CHERI architecture
where we make extensive use of address spaces to differentiate between
capabilities and pointers. When merging the upstream changes I usually
run into some test failures or runtime crashes because the wrong kind of
address space is passed to a function. By converting the LangAS enum to a
C++11 we can catch these errors at compile time. Additionally, it is now
obvious from the function signature which kind of address space it expects.
I found the following errors while writing this patch:
- ItaniumRecordLayoutBuilder::LayoutField was passing a clang AST address
space to TargetInfo::getPointer{Width,Align}()
- TypePrinter::printAttributedAfter() prints the numeric value of the
clang AST address space instead of the target address space.
However, this code is not used so I kept the current behaviour
- initializeForBlockHeader() in CGBlocks.cpp was passing
LangAS::opencl_generic to TargetInfo::getPointer{Width,Align}()
- CodeGenFunction::EmitBlockLiteral() was passing a AST address space to
TargetInfo::getPointerWidth()
- CGOpenMPRuntimeNVPTX::translateParameter() passed a target address space
to Qualifiers::addAddressSpace()
- CGOpenMPRuntimeNVPTX::getParameterAddress() was using
llvm::Type::getPointerTo() with a AST address space
- clang_getAddressSpace() returns either a LangAS or a target address
space. As this is exposed to C I have kept the current behaviour and
added a comment stating that it is probably not correct.
Other than this the patch should not cause any functional changes.
Reviewers: yaxunl, pcc, bader
Reviewed By: yaxunl, bader
Subscribers: jlebar, jholewinski, nhaehnle, Anastasia, cfe-commits
Differential Revision: https://reviews.llvm.org/D38816
llvm-svn: 315871
|
| |
|
|
|
|
|
| |
These pragmas work around a bug in VC 1911 that isn't present in clang,
and clang warns about them.
llvm-svn: 315699
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently Clang uses default address space (0) to represent private address space for OpenCL
in AST. There are two issues with this:
Multiple address spaces including private address space cannot be diagnosed.
There is no mangling for default address space. For example, if private int* is emitted as
i32 addrspace(5)* in IR. It is supposed to be mangled as PUAS5i but it is mangled as
Pi instead.
This patch attempts to represent OpenCL private address space explicitly in AST. It adds
a new enum LangAS::opencl_private and adds it to the variable types which are implicitly
private:
automatic variables without address space qualifier
function parameter
pointee type without address space qualifier (OpenCL 1.2 and below)
Differential Revision: https://reviews.llvm.org/D35082
llvm-svn: 315668
|
| |
|
|
|
|
|
|
|
|
| |
This feature is not (yet) approved by the C++ committee, so this is liable to
be reverted or significantly modified based on committee feedback.
No functionality change intended for existing code (a new type must be defined
in namespace std to take advantage of this feature).
llvm-svn: 315662
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When declaring an entity in the "purview" of a module, it's never a
redeclaration of an entity in the purview of a default module or in no module
("in the global module"). Don't consider those other declarations as possible
redeclaration targets if they're not visible, and reject any cases where we
pick a prior visible declaration that violates this rule.
This reinstates r315251 and r315256, reverted in r315309 and r315308
respectively, tweaked to avoid triggering a linkage calculation when declaring
implicit special members (this exposed our pre-existing issue with typedef
names for linkage changing the linkage of types whose linkage has already been
computed and cached in more cases). A testcase for that regression has been
added in r315366.
llvm-svn: 315379
|
| |
|
|
|
|
| |
This reverts commit r315251. See the original commit thread for reason.
llvm-svn: 315309
|
| |
|
|
|
|
|
|
| |
DeclContext for a declaration in the global module."
This reverts commit r315256. See the original commit thread for reason.
llvm-svn: 315308
|
| |
|
|
|
|
|
|
|
|
| |
declaration in the global module.
This works around a language issue where adding a typedef name for linkage
purposes changes the linkage of an already-defined class after it becomes
complete.
llvm-svn: 315256
|
| |
|
|
|
|
|
|
|
|
| |
When declaring an entity in the "purview" of a module, it's never a
redeclaration of an entity in the purview of a default module or in no module
("in the global module"). Don't consider those other declarations as possible
redeclaration targets if they're not visible, and reject any cases where we
pick a prior visible declaration that violates this rule.
llvm-svn: 315251
|
| |
|
|
| |
llvm-svn: 315196
|
| |
|
|
| |
llvm-svn: 315185
|
| |
|
|
|
|
| |
rdar://34811344
llvm-svn: 315103
|
| |
|
|
|
|
|
|
| |
Fixes PR19741.
Differential revision: https://reviews.llvm.org/D38483
llvm-svn: 314865
|
| |
|
|
| |
llvm-svn: 314754
|
| |
|
|
|
|
|
|
|
|
| |
directives.
The argument of the `device` clause in target-based executable
directives must be captured to support codegen for the `target`
directives with the `depend` clauses.
llvm-svn: 314686
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch relates to: https://reviews.llvm.org/D33666 This adds support
for template parameters to be passed to the address_space attribute.
The main goal is to add further flexibility to the attribute and allow
for it to be used easily with templates.
The main additions are a new type (DependentAddressSpaceType) alongside
its TypeLoc and its mangling. As well as the logic required to support
dependent address spaces which mainly resides in TreeTransform.h and
SemaType.cpp.
llvm-svn: 314649
|
| |
|
|
| |
llvm-svn: 314581
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Apparently, the MSVC SDK has a strange implementation that
causes a number of implicit functions as well as a template member
function of the IUnknown type. This patch allows these as InterfaceLike
types as well.
Additionally, it corrects the behavior where extern-C++ wrapped around an
Interface-Like type would permit an interface-like type to exist in a namespace.
Differential Revision: https://reviews.llvm.org/D38303
llvm-svn: 314557
|
| |
|
|
|
|
|
|
| |
Patch by S. Gilles!
Differential Revision: https://reviews.llvm.org/D28148
llvm-svn: 314499
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
C11 standard refers to the unsigned counterpart of the type ptrdiff_t
in the paragraph 7.21.6.1p7 where it defines the format specifier %tu.
In Clang (in PrintfFormatString.cpp, lines 508-510) there is a FIXME for this case,
in particular, Clang didn't diagnose %tu issues at all, i.e.
it didn't emit any warnings on the code printf("%tu", 3.14).
In this diff we add a method getUnsignedPointerDiffType for getting the corresponding type
similarly to how it's already done in the other analogous cases (size_t, ssize_t, ptrdiff_t etc)
and fix -Wformat diagnostics for %tu plus the emitted fix-it as well.
Test plan: make check-all
Differential revision: https://reviews.llvm.org/D38270
llvm-svn: 314470
|