Commit Graph

174 Commits

Author SHA1 Message Date
Kazu Hirata 4db2e4cebe Use {DenseSet,SetVector,SmallPtrSet}::contains (NFC) 2021-10-30 19:00:19 -07:00
Kazu Hirata 57b40b5f34 [AST, CodeGen, Driver] Use llvm::is_contained (NFC) 2021-10-12 09:19:49 -07:00
Jim Lin 8a2d375a77 [NFC] [Clang]: fix spelling mistake in assert message
Reviewed By: Jim

Differential Revision: https://reviews.llvm.org/D71541
2021-04-12 14:10:52 +08:00
Richard Smith 4eff2beefb [c++20] consteval functions don't get vtable slots.
For the Itanium C++ ABI, this implements the rule added in
https://github.com/itanium-cxx-abi/cxx-abi/pull/83

For the MS C++ ABI, this implements the direction that seemed most
plausible based on personal correspondence with MSVC developers, but is
subject to change as they decide their ABI rule.
2020-06-30 18:22:09 -07:00
Leonard Chan 71568a9e28 [clang] Frontend components for the relative vtables ABI (round 2)
This patch contains all of the clang changes from D72959.

- Generalize the relative vtables ABI such that it can be used by other targets.
- Add an enum VTableComponentLayout which controls whether components in the
  vtable should be pointers to other structs or relative offsets to those structs.
  Other ABIs can change this enum to restructure how components in the vtable
  are laid out/accessed.
- Add methods to ConstantInitBuilder for inserting relative offsets to a
  specified position in the aggregate being constructed.
- Fix failing tests under new PM and ASan and MSan issues.

See D72959 for background info.

Differential Revision: https://reviews.llvm.org/D77592
2020-06-11 11:17:08 -07:00
Leonard Chan 7201272d4c Revert "[clang] Frontend components for the relative vtables ABI"
This reverts commit 2e009dbcb3.

Reverting since there were some test failures on buildbots that used the
new pass manager. ASan and MSan are also finding some bugs in this that
I'll need to address.
2020-06-10 13:50:05 -07:00
Leonard Chan 2e009dbcb3 [clang] Frontend components for the relative vtables ABI
This patch contains all of the clang changes from D72959.

- Generalize the relative vtables ABI such that it can be used by other targets.
- Add an enum VTableComponentLayout which controls whether components in the
  vtable should be pointers to other structs or relative offsets to those structs.
  Other ABIs can change this enum to restructure how components in the vtable
  are laid out/accessed.
- Add methods to ConstantInitBuilder for inserting relative offsets to a
  specified position in the aggregate being constructed.

See D72959 for background info.

Differential Revision: https://reviews.llvm.org/D77592
2020-06-10 12:48:10 -07:00
Richard Smith 6e73fee780 List implicit operator== after implicit destructors in a vtable.
Summary:
We previously listed first declared members, then implicit operator=,
then implicit operator==, then implicit destructors. Per discussion on
https://github.com/itanium-cxx-abi/cxx-abi/issues/88, put the implicit
equality comparison operators at the very end, after all special member
functions.

This reinstates add2b7e44a, reverted in
commit 89e43f04ba, with a fix for 32-bit
targets.

Reviewers: rjmccall

Subscribers: cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D72897
2020-01-21 15:54:40 -08:00
Vladimir Vereschaka 89e43f04ba Revert "List implicit operator== after implicit destructors in a vtable."
This reverts commit add2b7e44a.

Failed "Clang::virtual-compare.cpp" test on the arm builders.
See
http://lab.llvm.org:8011/builders/llvm-clang-win-x-armv7l/builds/3169
for details.
2020-01-21 13:07:56 -08:00
Richard Smith add2b7e44a List implicit operator== after implicit destructors in a vtable.
Summary:
We previously listed first declared members, then implicit operator=,
then implicit operator==, then implicit destructors. Per discussion on
https://github.com/itanium-cxx-abi/cxx-abi/issues/88, put the implicit
equality comparison operators at the very end, after all special member
functions.

Reviewers: rjmccall

Subscribers: cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D72897
2020-01-19 18:31:36 -08:00
Simon Pilgrim 54b2914acc Fix "pointer is null" static analyzer warnings. NFCI.
Use castAs<> instead of getAs<> since the pointers are dereferenced immediately and castAs will perform the null assertion for us.
2020-01-12 22:08:56 +00:00
Jonas Devlieghere 2b3d49b610 [Clang] Migrate llvm::make_unique to std::make_unique
Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of (hopefully) all the llvm::make_unique instances across the monorepo.

Differential revision: https://reviews.llvm.org/D66259

llvm-svn: 368942
2019-08-14 23:04:18 +00:00
Rui Ueyama 49a3ad21d6 Fix parameter name comments using clang-tidy. NFC.
This patch applies clang-tidy's bugprone-argument-comment tool
to LLVM, clang and lld source trees. Here is how I created this
patch:

$ git clone https://github.com/llvm/llvm-project.git
$ cd llvm-project
$ mkdir build
$ cd build
$ cmake -GNinja -DCMAKE_BUILD_TYPE=Debug \
    -DLLVM_ENABLE_PROJECTS='clang;lld;clang-tools-extra' \
    -DCMAKE_EXPORT_COMPILE_COMMANDS=On -DLLVM_ENABLE_LLD=On \
    -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ ../llvm
$ ninja
$ parallel clang-tidy -checks='-*,bugprone-argument-comment' \
    -config='{CheckOptions: [{key: StrictMode, value: 1}]}' -fix \
    ::: ../llvm/lib/**/*.{cpp,h} ../clang/lib/**/*.{cpp,h} ../lld/**/*.{cpp,h}

llvm-svn: 366177
2019-07-16 04:46:31 +00:00
Fangrui Song 899d13926d Use llvm::stable_sort
llvm-svn: 359098
2019-04-24 14:43:05 +00:00
Fangrui Song 75e74e077c Range-style std::find{,_if} -> llvm::find{,_if}. NFC
llvm-svn: 357359
2019-03-31 08:48:19 +00:00
Anastasia Stulova c61eaa5920 Rename getTypeQualifiers to getMethodQualifiers.
Use more descriptive name for the method qualifiers getter.

Differential Revision: https://reviews.llvm.org/D56792

llvm-svn: 352349
2019-01-28 11:37:49 +00:00
Serge Guelton be88539b85 Replace llvm::isPodLike<...> by llvm::is_trivially_copyable<...>
As noted in https://bugs.llvm.org/show_bug.cgi?id=36651, the specialization for
isPodLike<std::pair<...>> did not match the expectation of
std::is_trivially_copyable which makes the memcpy optimization invalid.

This patch renames the llvm::isPodLike trait into llvm::is_trivially_copyable.
Unfortunately std::is_trivially_copyable is not portable across compiler / STL
versions. So a portable version is provided too.

Note that the following specialization were invalid:

    std::pair<T0, T1>
    llvm::Optional<T>

Tests have been added to assert that former specialization are respected by the
standard usage of llvm::is_trivially_copyable, and that when a decent version
of std::is_trivially_copyable is available, llvm::is_trivially_copyable is
compared to std::is_trivially_copyable.

As of this patch, llvm::Optional is no longer considered trivially copyable,
even if T is. This is to be fixed in a later patch, as it has impact on a
long-running bug (see r347004)

Note that GCC warns about this UB, but this got silented by https://reviews.llvm.org/D50296.

Differential Revision: https://reviews.llvm.org/D54472

llvm-svn: 351701
2019-01-20 21:19:56 +00:00
Chandler Carruth 2946cd7010 Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636
2019-01-19 08:50:56 +00:00
Fangrui Song 3117b17bc5 Use llvm::{all,any,none}_of instead std::{all,any,none}_of. NFC
llvm-svn: 344859
2018-10-20 17:53:42 +00:00
Fangrui Song 1d38c13f6e Use the container form llvm::sort(C, ...)
There are a few leftovers of rC343147 that are not (\w+)\.begin but in
the form of ([-[:alnum:]>.]+)\.begin or spanning two lines. Change them
to use the container form in this commit. The 12 occurrences have been
inspected manually for safety.

llvm-svn: 343425
2018-09-30 21:41:11 +00:00
Fangrui Song 55fab260ca llvm::sort(C.begin(), C.end(), ...) -> llvm::sort(C, ...)
Summary: The convenience wrapper in STLExtras is available since rL342102.

Reviewers: rsmith, #clang, dblaikie

Reviewed By: rsmith, #clang

Subscribers: mgrang, arphaman, kadircet, cfe-commits

Differential Revision: https://reviews.llvm.org/D52576

llvm-svn: 343147
2018-09-26 22:16:28 +00:00
Fangrui Song 6907ce2f8f Remove trailing space
sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h}

llvm-svn: 338291
2018-07-30 19:24:48 +00:00
Reid Kleckner 138ab4947c Fix a mangling failure on clang-cl C++17
MethodVFTableLocations in MigrosoftVTableContext contains canonicalized
decl. But, it's sometimes asked to lookup for non-canonicalized decl,
and that causes assertion failure, and compilation failure.

Fixes PR37481.

Patch by Taiju Tsuiki!

Differential Revision: https://reviews.llvm.org/D46929

llvm-svn: 332639
2018-05-17 18:12:18 +00:00
Adrian Prantl 9fc8faf9e6 Remove \brief commands from doxygen comments.
This is similar to the LLVM change https://reviews.llvm.org/D46290.

We've been running doxygen with the autobrief option for a couple of
years now. This makes the \brief markers into our comments
redundant. Since they are a visual distraction and we don't want to
encourage more \brief markers in new code either, this patch removes
them all.

Patch produced by

for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done
for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done

Differential Revision: https://reviews.llvm.org/D46320

llvm-svn: 331834
2018-05-09 01:00:01 +00:00
Alexander Kornienko 2a8c18d991 Fix typos in clang
Found via codespell -q 3 -I ../clang-whitelist.txt
Where whitelist consists of:

  archtype
  cas
  classs
  checkk
  compres
  definit
  frome
  iff
  inteval
  ith
  lod
  methode
  nd
  optin
  ot
  pres
  statics
  te
  thru

Patch by luzpaz! (This is a subset of D44188 that applies cleanly with a few
files that have dubious fixes reverted.)

Differential revision: https://reviews.llvm.org/D44188

llvm-svn: 329399
2018-04-06 15:14:32 +00:00
Reid Kleckner cbec0269ba Fix some DenseMap use-after-rehash bugs and hoist MethodVFTableLocation
This re-lands r328845 with fixes for crbug.com/827810.

The initial motiviation was to hoist MethodVFTableLocation to global
scope so it could be forward declared.

In this patch, I noticed that MicrosoftVTableContext uses some risky
patterns. It has methods that return references to data stored in
DenseMaps. I've made some of them return by value for trivial structs
and I've moved some things into separate allocations.

llvm-svn: 329007
2018-04-02 20:00:39 +00:00
Nico Weber e7c7d70278 Revert r328845, it caused crbug.com/827810.
llvm-svn: 328922
2018-03-31 18:26:25 +00:00
Reid Kleckner 9e3eb9f9d2 Hoist MethodVFTableLocation out of MicrosoftVTableContext, NFC
This allows forward declaring it so that we can add it to
MicrosoftMangleContext::mangleVirtualMemPtrThunk without including
VTableBuilder.h. That saves a hashtable lookup when emitting virtual
member pointer functions.

It also shortens a really long type name. This struct has "VFtable" in
the name, so it seems pretty unlikely that someone will assume it is
generally useful for non-MS C++ ABI stuff.

llvm-svn: 328845
2018-03-29 22:42:24 +00:00
Reid Kleckner eed882022f [MS] Fix bug in method vfptr location code
We were assuming that vbtable indices were assigned in layout order in
our comparison, which is not the case. When a virtual method, such as
the destructor, appears in multiple vftables, the vftable that appears
first in object layout order is the one that points to the main
implementation of that method. The later vftables use thunks.

In this layout, we adjusted "this" in the main implementation by the
amount that is appropriate for 'B' instead of 'A', even though the main
implementation is found in D's vftable for A:

  struct A {
    virtual ~A() {}
  };
  struct B {
    virtual ~B() {}
  };
  struct C : virtual B {};
  struct D : virtual A, C {};

D's layout looks like:
   0 D subobject (empty)
   0 C base suboject
   8 A base subobject
  16 B base subobject

With this fix, we correctly adjust by -8 in D's deleting destructor
instead of -16.

Fixes PR36921.

llvm-svn: 328723
2018-03-28 18:23:35 +00:00
Mandeep Singh Grang c205d8cc8d [clang] Change std::sort to llvm::sort in response to r327219
r327219 added wrappers to std::sort which randomly shuffle the container before
sorting.  This will help in uncovering non-determinism caused due to undefined
sorting order of objects having the same key.

To make use of that infrastructure we need to invoke llvm::sort instead of
std::sort.

llvm-svn: 328636
2018-03-27 16:50:00 +00:00
Benjamin Kramer acfa339e15 Refactor overridden methods iteration to avoid double lookups.
Convert most uses to range-for loops. No functionality change intended.

llvm-svn: 320954
2017-12-17 23:52:45 +00:00
Reid Kleckner dd6fc83cb4 [ms] Fix vbtable index for covariant overrides of vbase methods
Overriding a method from a virtual base with a covariant return type
consumes a slot from the vftable in the virtual base. This can make it
impossible to implement certain diamond inheritance hierarchies, but we
have to follow along for compatibility in the simple cases.

This patch only affects our vtable dumper and member pointer function
mangling, since all other callers of getMethodVFTableLocation seem to
recompute VBTableIndex instead of using the one in the method location.

Patch by David Majnemer

llvm-svn: 312017
2017-08-29 17:40:04 +00:00
Peter Collingbourne 2849c4e841 CodeGen: New vtable group representation: struct of vtable arrays.
In a future change, this representation will allow us to use the new inrange
annotation on getelementptr to allow the optimizer to split vtable groups.

Differential Revision: https://reviews.llvm.org/D22296

llvm-svn: 289584
2016-12-13 20:40:39 +00:00
Justin Lebar 76d4defe41 [AST] Don't use make_pointee_iterator in VTableBuilder.
Our implementation of make_pointee_iterator seems to be causing MSVC
2015 to crash, so I'm going to remove it.

llvm-svn: 283790
2016-10-10 19:26:22 +00:00
Justin Lebar 03b0620192 Use unique_ptr for VTableBuilder::VBaseInfo map.
Reviewers: timshen

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D25424

llvm-svn: 283772
2016-10-10 16:26:36 +00:00
Justin Lebar e920cfadf0 Use unique_ptr for VTableBuilder::VFTableLayouts map.
Reviewers: timshen

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D25423

llvm-svn: 283771
2016-10-10 16:26:33 +00:00
Justin Lebar 562914e505 Use unique_ptr for VPtrLocationsMap and VPtrInfoVector.
Reviewers: timshen

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D25422

llvm-svn: 283770
2016-10-10 16:26:29 +00:00
Justin Lebar 072f9ba99a [AST] Use unique_ptr for VTableLayout.
Reviewers: timshen

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D25421

llvm-svn: 283769
2016-10-10 16:26:24 +00:00
Reid Kleckner 8ad06d6546 [MS] Improve VPtrInfo field names and doc comments
'ReusingBase' was a terrible name. It might actually refer to the most
derived class, which is not a base. 'BaseWithVPtr' was also bad, since
again, it could refer to the most derived class. It was actually the
first base to introduce the vptr, so now it is 'IntroducingObject'.

llvm-svn: 276120
2016-07-20 14:40:25 +00:00
Reid Kleckner ad1e22bf33 Re-land "[MS] Don't expect vftables to be provided for extern template 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
2016-06-29 18:29:21 +00:00
Reid Kleckner f981bcb3a0 Revert "[MS] Don't expect vftables to be provided for extern template instantiations"
This reverts commit r273296, it broke the Windows self-host.

llvm-svn: 273305
2016-06-21 19:51:52 +00:00
Reid Kleckner 93b4b2e386 [MS] Don't expect vftables to be provided for extern template instantiations
MSVC doesn't provide them. PR28223

I left behind the machinery in case we want to resurrect available_externally
vftable emission to support devirtualization.

Reviewers: majnemer

Differential Revision: http://reviews.llvm.org/D21544

llvm-svn: 273296
2016-06-21 18:39:55 +00:00
David Majnemer 2d8b2008c8 Revert "Revert r260388 "[MS ABI] Never reference dllimport'd vtables""
This reverts commit r260449.

We would supress our emission of vftable definitions if we thought
another translation unit would provide the definition because we saw an
explicit instantiation declaration.  This is not the case with
dllimport, we want to synthesize a definition of the vftable regardless.

This fixes PR26569.

llvm-svn: 260548
2016-02-11 17:49:28 +00:00
Hans Wennborg 8fab56e0dc Revert r260388 "[MS ABI] Never reference dllimport'd vtables"
This caused the compiler to fail with "invalid linkage type
for global declaration" (PR26569).

llvm-svn: 260449
2016-02-10 22:18:37 +00:00
David Majnemer 1b2d0b4637 [MS ABI] Never reference dllimport'd vtables
Referencing a dllimported vtable is impossible in a constexpr
constructor.  It would be friendlier to C++ programmers if we
synthesized a copy of the vftable which referenced imported virtual
functions.  This would let us initialize the object in a way which
preserves both the intent to import functionality from another DLL while
also making constexpr work.

Differential Revision: http://reviews.llvm.org/D17061

llvm-svn: 260388
2016-02-10 17:40:47 +00:00
David Majnemer 70effde0af [MS ABI] Let arbitrary entities participate in vftable ordering
In the Microsoft ABI, the vftable is laid out in the order in the
declaration order of the entities defined within it.

Obviously, only virtual methods end up in the vftable but they will be
placed into the table at the same position as the first entity with the
same name.

llvm-svn: 253523
2015-11-19 00:03:54 +00:00
Angel Garcia Gomez 637d1e6694 Roll-back r250822.
Summary: It breaks the build for the ASTMatchers

Subscribers: klimek, cfe-commits

Differential Revision: http://reviews.llvm.org/D13893

llvm-svn: 250827
2015-10-20 13:23:58 +00:00
Angel Garcia Gomez b5250d3448 Apply modernize-use-default to clang.
Summary: Replace empty bodies of default constructors and destructors with '= default'.

Reviewers: bkramer, klimek

Subscribers: klimek, alexfh, cfe-commits

Differential Revision: http://reviews.llvm.org/D13890

llvm-svn: 250822
2015-10-20 12:52:55 +00:00
Benjamin Kramer a37e765497 [VTableBuilder] Use range-based for loops. No functional change intended
llvm-svn: 243222
2015-07-25 17:10:49 +00:00
Benjamin Kramer 0cfa68e01b [VTableBuilder] Turn functors into lambdas
No functional change intended.

llvm-svn: 243221
2015-07-25 16:31:30 +00:00