Disallow calls to templated `getTrailingObjects` if there is a single trailing type (strict mode). Add `getTrailingObjectsNonStrict` for cases when it's not possible to know statically if there will be a single or multiple trailing types (like in OpenMPClause.h) to bypass the struct checks. This will ensure that future users of TrailingObjects class do not accidently use the templated `getTrailingObjects` when they have a single trailing type.
- Use private inheritance for TrailingObjects as recommended in TrailingObjects.h - No need to define `numTrailingObjects` for the last trailing type. - Fix comment typos.
Add a specialization of getTrailingObjects() for a single trailing type. This is a common case and with the specialization you don't need to specify the single trailing type redundantly. Also add an overload for getTrailingObjects which takes size and returns an ArryaRef/MutableArrayRef as that's a common use case as well.
Add `llvm::uninitialized_copy` that accepts a range instead of start/end iterator for the source of the copy.
Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68942 llvm-svn: 374773
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
MSVC appears to be getting confused as to whether OverloadToken is supposed to be public or not. This was discovered by code in Swift, and has been reported to microsoft by hughbe: https://connect.microsoft.com/VisualStudio/feedback/details/3116517 Differential Revision: https://reviews.llvm.org/D29880 llvm-svn: 296497
No functionality change intended. llvm-svn: 284733
Summary: This change fixes issues with `LLVM_CONSTEXPR` functions and `TrailingObjects::FixedSizeStorage`. In particular, some of the functions marked `LLVM_CONSTEXPR` used by `FixedSizeStorage` were not implemented such that they evaluate successfully as part of a constant expression despite constant arguments. This change also implements a more traditional template-meta path to accommodate MSVC, and adds unit tests for `FixedSizeStorage`. Drive-by fix: the access control for members of `TrailingObjectsImpl` is tightened. Reviewers: faisalv, rsmith, aaron.ballman Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D22668 llvm-svn: 277270
compiler-specific issues. Instead, repeat an 'operator delete' definition in each derived class that is actually deleted, and give up on the static type safety of an error when sized delete is accidentally used on a type derived from TrailingObjects. llvm-svn: 260190