4613 Commits

Author SHA1 Message Date
Paulo Matos
55aeb23fe0 [clang][WebAssembly] Implement support for table types and builtins
This commit implements support for WebAssembly table types and
respective builtins. Table tables are WebAssembly objects to store
reference types. They have a large amount of semantic restrictions
including, but not limited to, only being allowed to be declared
at the top-level as static arrays of zero-length. Not being arguments
or result of functions, not being stored ot memory, etc.

This commit introduces the __attribute__((wasm_table)) to attach to
arrays of WebAssembly reference types. And the following builtins to
manage tables:

* ref   __builtin_wasm_table_get(table, idx)
* void  __builtin_wasm_table_set(table, idx, ref)
* uint  __builtin_wasm_table_size(table)
* uint  __builtin_wasm_table_grow(table, ref, uint)
* void  __builtin_wasm_table_fill(table, idx, ref, uint)
* void  __builtin_wasm_table_copy(table, table, uint, uint, uint)

This commit also enables reference-types feature at bleeding-edge.

This is joint work with Alex Bradbury (@asb).

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D139010
2023-06-10 15:53:13 +02:00
Sam McCall
e3f91acad3 Fix namespace of operator<< defn 2023-06-08 01:36:59 +02:00
Artem Belevich
0f49116e26 [CUDA] Update Kepler(sm_3*) support info.
sm_30 and sm_32 were removed in cuda-11.0
sm_35 and sm_37 were removed in cuda-12.0

Differential Revision: https://reviews.llvm.org/D152027
2023-06-02 14:16:13 -07:00
Jan Svoboda
e6830b6028 [clang][modules] NFCI: Extract optionality out of Module::{Header,DirectoryName}
Most users of `Module::Header` already assume its `Entry` is populated. Enforce this assumption in the type system and handle the only case where this is not the case by wrapping the whole struct in `std::optional`. Do the same for `Module::DirectoryName`.

Depends on D151584.

Reviewed By: benlangmuir

Differential Revision: https://reviews.llvm.org/D151586
2023-05-30 21:06:51 -07:00
Bryan Chan
9f6250f591 [Clang][AArch64][SME] Add vector load/store (ld1/st1) intrinsics
This patch adds support for the following SME ACLE intrinsics (as defined
in https://arm-software.github.io/acle/main/acle.html):

  - svld1_hor_za8      // also for _za16, _za32, _za64 and _za128
  - svld1_hor_vnum_za8 // also for _za16, _za32, _za64 and _za128
  - svld1_ver_za8      // also for _za16, _za32, _za64 and _za128
  - svld1_ver_vnum_za8 // also for _za16, _za32, _za64 and _za128
  - svst1_hor_za8      // also for _za16, _za32, _za64 and _za128
  - svst1_hor_vnum_za8 // also for _za16, _za32, _za64 and _za128
  - svst1_ver_za8      // also for _za16, _za32, _za64 and _za128
  - svst1_ver_vnum_za8 // also for _za16, _za32, _za64 and _za128

SveEmitter.cpp is extended to generate arm_sme.h (currently named
arm_sme_draft_spec_subject_to_change.h) and other SME definitions from
arm_sme.td, which is modeled after arm_sve.td. Common TableGen definitions
are moved into arm_sve_sme_incl.td.

Co-authored-by: Sagar Kulkarni <sagar.kulkarni1@huawei.com>

Reviewed By: sdesmalen, kmclaughlin

Differential Revision: https://reviews.llvm.org/D127910
2023-05-28 21:08:13 -04:00
M. Zeeshan Siddiqui
e621757365 [Clang][BFloat16] Upgrade __bf16 to arithmetic type, change mangling, and extend excess precision support
Pursuant to discussions at
https://discourse.llvm.org/t/rfc-c-23-p1467r9-extended-floating-point-types-and-standard-names/70033/22,
this commit enhances the handling of the __bf16 type in Clang.
- Firstly, it upgrades __bf16 from a storage-only type to an arithmetic
  type.
- Secondly, it changes the mangling of __bf16 to DF16b on all
  architectures except ARM. This change has been made in
  accordance with the finalization of the mangling for the
  std::bfloat16_t type, as discussed at
  https://github.com/itanium-cxx-abi/cxx-abi/pull/147.
- Finally, this commit extends the existing excess precision support to
  the __bf16 type. This applies to hardware architectures that do not
  natively support bfloat16 arithmetic.
Appropriate tests have been added to verify the effects of these
changes and ensure no regressions in other areas of the compiler.

Reviewed By: rjmccall, pengfei, zahiraam

Differential Revision: https://reviews.llvm.org/D150913
2023-05-27 13:33:50 +08:00
Jan Svoboda
d6e617c8ef [clang][modules] NFCI: Use DirectoryEntryRef for umbrella directory
This removes some deprecated uses of `DirectoryEntry::getName()`.

Depends on D151581.

Differential Revision: https://reviews.llvm.org/D151584
2023-05-26 15:30:28 -07:00
Jan Svoboda
924912956e [clang][modules] NFCI: Distinguish as-written and effective umbrella directories
For modules with umbrellas, we track how they were written in the module map. Unfortunately, the getter for the umbrella directory conflates the "as written" directory and the "effective" directory (either the written one or the parent of the written umbrella header).

This patch makes the distinction between "as written" and "effective" umbrella directories clearer. No functional change intended.

Reviewed By: benlangmuir

Differential Revision: https://reviews.llvm.org/D151581
2023-05-26 15:14:16 -07:00
Jan Svoboda
bdc3ce9e8f [clang] Make FileEntryRef::getDir() return the as-requested DirectoryEntryRef
For redirected file entries, `FileEntryRef::getDir()` returns the parent directory entry of the target file entry. This differs from `FileEntry::getDir()` that always returns the parent directory that was last used to look up that file.

After switching from `FileEntry` to `FileEntryRef` for umbrella headers in D142113, this discrepancy became observable and caused Clang to emit incorrect diagnostics.

This patch changes Clang so that it always associates `FileEntryRef` with the parent directory that was used to look it up. This brings its behavior closer to `FileEntry`, but without the hacky mutation.

This also ensures that `llvm::sys::path::parent_path(FileRef->getNameAsRequested()) == FileRef->getDir()->getName()`. Previously, `FileRef->getDir()` would fall underneath the redirecting VFS into the world of on-disk paths.

Reviewed By: benlangmuir, rmaz

Differential Revision: https://reviews.llvm.org/D151398
2023-05-25 12:36:57 -07:00
Artem Belevich
ffb635cb2d [CUDA] bump supported CUDA version to 12.1/11.8
Differential Revision: https://reviews.llvm.org/D151361
2023-05-25 11:57:55 -07:00
Craig Topper
6006d43e2d LLVM_FALLTHROUGH => [[fallthrough]]. NFC
Reviewed By: MaskRay

Differential Revision: https://reviews.llvm.org/D150996
2023-05-24 12:40:10 -07:00
John Brawn
78bf8a0a22 [clang] Don't define predefined macros multiple times
Fix several instances of macros being defined multiple times
in several targets. Most of these are just simple duplication in a
TargetInfo or OSTargetInfo of things already defined in
InitializePredefinedMacros or InitializeStandardPredefinedMacros,
but there are a few that aren't:
 * AArch64 defines a couple of feature macros for armv8.1a that are
   handled generically by getTargetDefines.
 * CSKY needs to take care when CPUName and ArchName are the same.
 * Many os/target combinations result in __ELF__ being defined twice.
   Instead define __ELF__ just once in InitPreprocessor based on
   the Triple, which already knows what the object format is based
   on os and target.

These changes shouldn't change the final result of which macros are
defined, with the exception of the changes to __ELF__ where if you
explicitly specify the object type in the triple then this affects
if __ELF__ is defined, e.g. --target=i686-windows-elf results in it
being defined where it wasn't before, but this is more accurate as an
ELF file is in fact generated.

Differential Revision: https://reviews.llvm.org/D150966
2023-05-24 17:28:41 +01:00
Alex Bradbury
8e82376863 [clang][RISCV] Set HasLegalHalfType to true if zhinx is enabled
Now that codegen support for zhinx in landed (D149811), we should set
HasLegalHalfType=true for zhinx (see D145071 for the patch doing this
for zfh).

Differential Revision: https://reviews.llvm.org/D150777
2023-05-18 15:01:48 +01:00
Nico Weber
cf8c358dc9 Revert "[Lex] Warn when defining or undefining any builtin macro"
This reverts commit 22e3f587fd1ff97185014cb1ba723579ed2150d3.
Breaks check-clang on arm, see https://reviews.llvm.org/D144654#4349954

Also reverts follow-up "[AArch64] Don't redefine _LP64 and __LP64__"

This reverts commit e55d52cd34fb7a6a6617639d147b9d0abaceeeab.
2023-05-17 11:01:33 -04:00
John Brawn
e55d52cd34 [AArch64] Don't redefine _LP64 and __LP64__
Don't define these macros in AArch64TargetInfo::getTargetDefines, as
they're already defined in InitializePredefinedMacros and the
redefinition causes unwanted warnings with -Wsystem-headers.
2023-05-17 15:21:20 +01:00
Jonas Hahnfeld
53c03a3db1 [clang][modules] Add features for recent C++ versions
Add cplusplus20, cplusplus23, and cplusplus26 (but don't document
the latter, following the current policy).

Differential Revision: https://reviews.llvm.org/D150773
2023-05-17 15:18:50 +02:00
YunQiang Su
7983f8aca8 MIPS: allow o32 abi with 64bit CPU and 64 abi with 32bit triple
In general, MIPS support ELF format like
   ELF 32-bit LSB relocatable, MIPS, MIPS64 rel2 version 1 (SYSV)
and Linux's VDSO uses it.

Currently clang stop CMDs like
    clang -march=mips64r2 -mabi=32

While it is not needed now, since the the backend support the combination now.

This patch also allows something like
     clang --target=mipsel-linux-gnu -mabi=64
Since the triple can convert to right 64bit one automaticly.

Reviewed By: MaskRay

Differential Revision: https://reviews.llvm.org/D146269
2023-05-16 15:31:37 -07:00
Erich Keane
b763d6a4ed Add C++26 compile flags.
Now that we've updated to C++23, we need to add C++26/C++2c command line
flags, as discussed in
https://discourse.llvm.org/t/rfc-lets-just-call-it-c-26-and-forget-about-the-c-2c-business-at-least-internally/70383

Differential Revision: https://reviews.llvm.org/D150450
2023-05-15 08:56:16 -07:00
Weining Lu
0bbf3ddf5f [Clang][LoongArch] Add GPR alias handling without $ prefix
Currenlty there is a mismatch between LoongArch gcc and clang about
handling register name in inlineasm, i.e. gcc allows both `$`-prefixed
and non-prefiexed names for GPRs while clang only allows `$`-prefixed
one. This patch fixes this mismatch by adding non-prefixed GPR names
in clang.

Take `$r4` for example. With this patch, clang accepts `$r4`, `r4`,
`$a0` and `a0` like what gcc does.

Reviewed By: xen0n

Differential Revision: https://reviews.llvm.org/D136436
2023-05-13 12:08:59 +08:00
Yaxun (Sam) Liu
6adb9a0602 [AMDGPU] Emit predefined macro __AMDGCN_CUMODE__
Predefine __AMDGCN_CUMODE__ as 1 or 0 when compilation assumes CU or WGP modes.

If WGP mode is not supported, ignore -mno-cumode and emit a warning.

This is needed for implementing device functions like __smid
(312dff7b79/include/hip/amd_detail/amd_device_functions.h (L957))

Reviewed by: Matt Arsenault, Artem Belevich, Brian Sumner

Differential Revision: https://reviews.llvm.org/D145343
2023-05-12 18:50:52 -04:00
Konstantin Zhuravlyov
9d05727972 AMDGPU: Add basic gfx942 target
Differential Revision: https://reviews.llvm.org/D149983
2023-05-10 11:51:06 -04:00
Konstantin Zhuravlyov
1fc70210a6 AMDGPU: Add basic gfx941 target
Differential Revision: https://reviews.llvm.org/D149982
2023-05-10 11:51:06 -04:00
Qiu Chaofan
fa1f88cdec Reland "[PowerPC] Add target feature requirement to builtins"
This relands D143467 after fixing build failure with GCC.
2023-05-10 15:43:52 +08:00
Weining Lu
161716a713 [LoongArch] Support fcc* (condition flag) registers in inlineasm clobbers
Differential Revision: https://reviews.llvm.org/D150089
2023-05-09 14:55:50 +08:00
Vitaly Buka
af88d34f05 Revert "[PowerPC] Add target feature requirement to builtins"
Breaks PPC bots, see D143467.

This reverts commit 651b0e2e7afca926c3d4f8d7f988db40b9832676.
2023-05-08 11:16:55 -07:00
Sam McCall
14f0776550 Reland "Give NullabilityKind a printing operator<<"
This reverts commit 5326c9e480d70e16c2504cb5143524aff3ee2605.

The problem that caused the revert was downstream
(missing dep in user of clang).
2023-05-08 13:07:11 +02:00
Qiu Chaofan
651b0e2e7a [PowerPC] Add target feature requirement to builtins
Clang has mechanism to specify required target features of a built-in
function. This patch adds such definitions to Altivec, VSX, HTM,
PairedVec and MMA builtins.

This will help frontend to detect incompatible target features of
bulitin when using target attribute syntax.

Reviewed By: nemanjai, kamaub

Differential Revision: https://reviews.llvm.org/D143467
2023-05-08 17:53:25 +08:00
Caroline Tice
5326c9e480 Revert "Give NullabilityKind a printing operator<<"
This reverts commit 0a532207b8696d81e46017f444bd2257347f129b.

This breaks several of our tests. Have given reproducers to author.
Reverting this until author can fix the issue.
2023-05-05 23:37:30 -07:00
Alex Bradbury
560065b6ec [clang][RISCV] Set HasLegalHalfType to true if zfh is enabled
The desired semantics for HasLegalHalfType are slightly unclear in that
the comment for HasLegalHalfType says "True if the backend supports
operations on the half LLVM IR type." Which operations? We get very
limited scalar operations with zfhmin, more with zfh, and vector support
with zvfh. While the comment for hasLegalHalfType() says "Determine
whether _Float16 is supported on this target."

This patch sets HasLegalHalfType to true for zfh.

Differential Revision: https://reviews.llvm.org/D145071
2023-05-05 13:55:43 +01:00
Sam McCall
0a532207b8 Give NullabilityKind a printing operator<<
This is more useful for debug/test than getNullabilitySpelling:
 - default form has uglifying underscores
 - non-default form crashes on NullableResult
 - both return unhelpfully verbose strings for Unspecified
 - operator<< works with gtest, formatv, etc

Differential Revision: https://reviews.llvm.org/D149650
2023-05-04 23:24:51 +02:00
Mark de Wever
ba15d186e5 [clang] Use -std=c++23 instead of -std=c++2b
During the ISO C++ Committee meeting plenary session the C++23 Standard
has been voted as technical complete.

This updates the reference to c++2b to c++23 and updates the __cplusplus
macro.

Drive-by fixes c++1z -> c++17 and c++2a -> c++20 when seen.

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D149553
2023-05-04 19:19:52 +02:00
Krzysztof Drewniak
f0415f2a45 Re-land "[AMDGPU] Define data layout entries for buffers""
Re-land D145441 with data layout upgrade code fixed to not break OpenMP.

This reverts commit 3f2fbe92d0f40bcb46db7636db9ec3f7e7899b27.

Differential Revision: https://reviews.llvm.org/D149776
2023-05-03 19:43:56 +00:00
Krzysztof Drewniak
3f2fbe92d0 Revert "[AMDGPU] Define data layout entries for buffers"
This reverts commit f9c1ede2543b37fabe9f2d8f8fed5073c475d850.

Differential Revision: https://reviews.llvm.org/D149758
2023-05-03 16:11:00 +00:00
Krzysztof Drewniak
f9c1ede254 [AMDGPU] Define data layout entries for buffers
Per discussion at
https://discourse.llvm.org/t/representing-buffer-descriptors-in-the-amdgpu-target-call-for-suggestions/68798,
we define two new address spaces for AMDGCN targets.

The first is address space 7, a non-integral address space (which was
already in the data layout) that has 160-bit pointers (which are
256-bit aligned) and uses a 32-bit offset. These pointers combine a
128-bit buffer descriptor and a 32-bit offset, and will be usable with
normal LLVM operations (load, store, GEP). However, they will be
rewritten out of existence before code generation.

The second of these is address space 8, the address space for "buffer
resources". These will be used to represent the resource arguments to
buffer instructions, and new buffer intrinsics will be defined that
take them instead of <4 x i32> as resource arguments. ptr
addrspace(8). These pointers are 128-bits long (with the same
alignment). They must not be used as the arguments to getelementptr or
otherwise used in address computations, since they can have
arbitrarily complex inherent addressing semantics that can't be
represented in LLVM. Even though, like their address space 7 cousins,
these pointers have deterministic ptrtoint/inttoptr semantics, they
are defined to be non-integral in order to prevent optimizations that
rely on pointers being a [0, [addr_max]] value from applying to them.

Future work includes:
- Defining new buffer intrinsics that take ptr addrspace(8) resources.
- A late rewrite to turn address space 7 operations into buffer
intrinsics and offset computations.

This commit also updates the "fallback address space" for buffer
intrinsics to the buffer resource, and updates the alias analysis
table.

Depends on D143437

Reviewed By: arsenm

Differential Revision: https://reviews.llvm.org/D145441
2023-05-03 15:25:58 +00:00
Yeting Kuo
fa53ce0faa [RISCV] Enable strict fp for RISC-V in clang.
Reviewed By: craig.topper

Differential Revision: https://reviews.llvm.org/D149334
2023-05-03 08:32:27 +08:00
Craig Topper
fa42e7b6bc [RISCV] Merge RISCV::parseCPUKind and RISCV::checkCPUKind.
Similar for RISCV::parseTuneCPU and RISCV::checkTuneCPUKind.

This makes the CPUKind enum no longer part of the API. It wasn't
providing much value. It was only used to pass between the two
functions.

By removing it, we can remove a dependency on a tablegen generated
file from the RISCVTargetParser.h file. Then we can remove a
dependency from several CMakeLists.txt.
2023-05-01 13:00:05 -07:00
Manna, Soumi
e52a8b89ad [NFC][clang] Fix static analyzer concerns about AUTO_CAUSES_COPY
Reported by Coverity:

AUTO_CAUSES_COPY
Unnecessary object copies can affect performance

1. Inside "ODRHash.cpp" file, in clang::ODRHash::AddCXXRecordDecl(clang::CXXRecordDecl const *): Using the auto keyword without an & causes the copy of an object of type CXXBaseSpecifier.

2. Inside "Tokens.cpp" file, in clang::syntax::TokenBuffer::dumpForTests[abi:cxx11](): Using the auto keyword without an & causes the copy of an object of type DenseMapPair.

3. Inside "TargetID.cpp" file, in clang::getCanonicalTargetID[abi:cxx11](llvm::StringRef, llvm::StringMap<bool, llvm::MallocAllocator> const &): Using the auto keyword without an & causes the copy of an object of type pair.

Reviewed By: tahonermann, aaron.ballman

Differential Revision: https://reviews.llvm.org/D148639
2023-04-28 18:58:55 -07:00
Craig Topper
42e79d9771 [RISCV] Add attribute(riscv_rvv_vector_bits(N)) based on AArch64 arm_sve_vector_bits.
This allows the user to set the size of the scalable vector so they
can be used in structs and as the type of global variables. This works
by representing the type as a fixed vector instead of a scalable vector
in IR. Conversions to and from scalable vectors are made where necessary
like function arguments/returns and intrinsics.

This features has been requested here
https://github.com/riscv-non-isa/rvv-intrinsic-doc/issues/176
I know arm_sve_vector_bits is used by the Eigen library so this
could be used to port Eigen to RVV.

This patch adds a new preprocessor define `__riscv_v_fixed_vlen` that
is set when -mrvv_vector_bits is passed on the command line.

The code is largely based on the AArch64 code. A lot of code was
copy/pasted and then modiied to RVV. There may be some opportunities
for sharing.

This first patch only supports the LMUL=1 types. Additional changes
will be needed to support other LMULs. I have also not supported
mask vectors.

Differential Revision: https://reviews.llvm.org/D145088
2023-04-28 15:41:17 -07:00
Mingming Liu
4ab76b77ce [AArch64][InlineAsm]Add Clang support for flag output constraints
- Mention this change in Clang release notes

Before:
- Clang emits "invalid output constraint '=@cceq' in asm" https://gcc.godbolt.org/z/b9crfEo8h

After:
- For aarch64 targets (with __aarch64__ defined), Clang validates and parses flag output constraints to generate LLVM IR.

Differential Revision: https://reviews.llvm.org/D149123
2023-04-27 09:39:08 -07:00
Mingming Liu
739f5578c4 [NFC][Clang]Remove a reference on argument since 'Name' is not modified'
Reviewed By: nickdesaulniers

Differential Revision: https://reviews.llvm.org/D149274
2023-04-26 11:21:34 -07:00
Min-Yih Hsu
9b61708142 [M68k] Add basic Clang support for M68881/2
- Add the `-m68881` flag
  - Add floating point feature detection
  - Macro definitions

Differential Revision: https://reviews.llvm.org/D147481
2023-04-24 09:32:49 -07:00
Aaron Ballman
4475dd62d0 Fix file info comment; NFC
There is no TargetInfoImpl class any longer.
2023-04-24 08:36:27 -04:00
Stoorx
42d758bfa6 [clang] Return std::string_view from TargetInfo::getClobbers()
Change the return type of `getClobbers` function from `const char*`
to `std::string_view`. Update the function usages in CodeGen module.

The reasoning of these changes is to remove unsafe `const char*`
strings and prevent unnecessary allocations for constructing the
`std::string` in usages of `getClobbers()` function.

Differential Revision: https://reviews.llvm.org/D148799
2023-04-24 12:16:54 +03:00
Stoorx
40136ecefc [clang] Make access to submodules via iterator_range
In file `clang/lib/Basic/Module.cpp` the `Module` class had `submodule_begin()` and `submodule_end()` functions to retrieve corresponding iterators for private vector of Modules. This commit removes mentioned functions, and replaces all of theirs usages with `submodules()` function and range-based for-loops.

Differential Revision: https://reviews.llvm.org/D148954
2023-04-24 12:05:59 +03:00
David Tenty
8d2e9fc855 [PowerPC] Add function pointer alignment to DataLayout
The alignment of function pointers was added to the Datalayout by
D57335 but currently is unset for the Power target. This will cause us
to compute a conservative minimum alignment of one if places like
Value::getPointerAlignment.

This patch implements the function pointer alignment in the Datalayout
for the Power backend and Power targets in clang, so we can query the
value for a particular Power target.

We come up with the correct value one of two ways:

- If the target uses function descriptor objects (i.e. ELFv1 & AIX ABIs),
  then a function pointer points to the descriptor, so use the alignment
  we would emit the descriptor with.
- If the target doesn't use function descriptor objects (i.e. ELFv2), a
  function pointer points to the global entry point, so use the minimum
  alignment for code on Power (i.e. 4-bytes).

Reviewed By: nemanjai

Differential Revision: https://reviews.llvm.org/D147016
2023-04-18 13:00:27 -04:00
Stoorx
830b359d3a [clang] Return std::unique_ptr<TargetInfo> from AllocateTarget
In file 'clang/lib/Basic/Targets.cpp' the function 'AllocateTarget' had a raw pointer as a return type, which have been wrapped in the 'std::unique_ptr' in all usages.
This commit changes the signature of the function to return an instance of 'std::unique_ptr' directly.

Reviewed By: DavidSpickett

Differential Revision: https://reviews.llvm.org/D148574
2023-04-18 10:07:26 +00:00
Manna, Soumi
18a3d9e5b3 [NFC][clang] Fix coverity static analyzer concerns about AUTO_CAUSES_COPY
Reported by Coverity:

AUTO_CAUSES_COPY
Unnecessary object copies can affect performance.

1. [NFC] Fix auto keyword use without an & causes the copy of an object of type SimpleRegistryEntry in clang::getAttributePluginInstances()

2. [NFC] Fix auto keyword use without an & causes the copy of an object of type tuple in CheckStmtInlineAttr<clang::NoInlineAttr, 2>(clang::Sema &, clang::Stmt const *, clang::Stmt const *, clang::AttributeCommonInfo const &)

3. [NFC] Fix auto keyword use without an & causes the copy of an object of type QualType in <unnamed>::SystemZTargetCodeGenInfo::isVectorTypeBased(clang::Type const *, bool)

4. [NFC] Fix auto keyword use without an & causes the copy of an object of type Policy in <unnamed>::RISCVIntrinsicManagerImpl::InitIntrinsicList()

5. [NFC] Fix auto keyword use without an & causes the copy of an object of type pair in checkUndefinedButUsed(clang::Sema &)

Reviewed By: tahonermann

Differential Revision: <https://reviews.llvm.org/D147543>
2023-04-17 21:33:21 -04:00
Han Zhu
ee68f612ba Second try: [clang][cmake] Add options to pass in vcs repo and revision info
V2: Fix cmake error when -DLLVM_APPEND_VC_REV=OFF

Clang may be built in an environment where Git is not available. In our case,
Clang is part of a larger monorepo which is not Git-based, and
GenerateVersionFromVCS was not able to get source info.

Provide options to pass in repo and revision info from cmake.
```
cmake \
  -DCLANG_VC_REPOSITORY=abc://repo.url.com \
  -DCLANG_VC_REVISION=abcd1234 \
  ...
```
This would allow us to prepare the source info beforehand and pass it to the
clang binary.

Differential Revision: https://reviews.llvm.org/D148262
2023-04-17 10:54:28 -07:00
Han Zhu
c720c1db11 Revert "[clang][cmake] Add options to pass in vcs repo and revision info"
This reverts commit 1f5e737fc135bf991889a1364b8f8c5edc3953d2.
2023-04-17 10:09:27 -07:00
Han Zhu
1f5e737fc1 [clang][cmake] Add options to pass in vcs repo and revision info
Clang may be built in an environment where Git is not available. In our case,
Clang is part of a larger monorepo which is not Git-based, and
GenerateVersionFromVCS was not able to get source info.

Provide options to pass in repo and revision info from cmake.
```
cmake \
  -DCLANG_VC_REPOSITORY=abc://repo.url.com \
  -DCLANG_VC_REVISION=abcd1234 \
  ...
```
This would allow us to prepare the source info beforehand and pass it to the
clang binary.

Differential Revision: https://reviews.llvm.org/D148262
2023-04-17 09:50:18 -07:00