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

When --staged (or --cached) use the index for formatting as well, not just
for the line numbers to format. Without this change git-clang-format gets
the changed line numbers based on the index, but then formats these lines on
the working tree version of the file.

This is a problem when the working tree and index differ. One common case
would be (and is the motivation behind this patch) when applying the
suggested changes git-clang-format --staged, then forgetting to add the
applied changes. When git-clang-format --staged --diff is used in a
pre-commit hook in this scenario, then the hook would allow committing the
improperly formatted changes, as the file is correctly formatted in the work
tree.

Fixes #56797.

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

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

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

Refactor affine analysis helpers: the existing ones were using
unnecessary or improperly named arguments. NFC.

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

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

Add missing check in affine dependence analysis when dependence analysis
isn't possible due to the ops being in different affine scopes.  The
lack of such a check could lead to a crash or incorrect behavior in
several dependent utilities.

Reviewed By: ftynse

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

Fix build breakage due to 5c5af910.

```commit 5c5af910
Author: Jeff Niu <jeff@modular.com>
Date:   Tue Aug 9 22:07:35 2022 -0400

    [mlir][LLVMIR] "Modernize" Insert/ExtractValueOp ```

results in

```lib/Conversion/LLVMCommon/MemRefBuilder.cpp:170:70: error: call of overloaded ‘makeArrayRef<int64_t>(<brace-enclosed initializer list>)’ is ambiguous
       llvm::makeArrayRef<int64_t>({kStridePosInMemRefDescriptor,
       pos}));

llvm/include/llvm/ADT/ArrayRef.h:505:15: note: candidate: ‘llvm::ArrayRef<T> llvm::makeArrayRef(const std::vector<T>&) [with T = long int]’
   ArrayRef<T> makeArrayRef(const std::vector<T> &Vec) {
               ^~~~~~~~~~~~
llvm/include/llvm/ADT/ArrayRef.h:516:37: note: candidate: ‘llvm::ArrayRef<T> llvm::makeArrayRef(const llvm::ArrayRef<T>&) [with T = long int]’
   template <typename T> ArrayRef<T> makeArrayRef(const ArrayRef<T> &Vec) {
                                                                      ^

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

Apple Clang in Xcode 14 introduced a new feature for reducing the
overhead of objc_msgSend calls by deduplicating the setup calls for each
individual selector. This works by clang adding undefined symbols for
each selector called in a translation unit, such as `_objc_msgSend$foo`
for calling the `foo` method on any `NSObject`. There are 2
different modes for this behavior, the default directly does the setup
for `_objc_msgSend` and calls it, and the smaller option does the
selector setup, and then calls the standard `_objc_msgSend` stub
function.

The general overview of how this works is:

- Undefined symbols with the given prefix are collected
- The suffix of each matching undefined symbol is added as a string to
  `__objc_methname`
- A pointer is added for every method name in the `__objc_selrefs`
  section
- A `got` entry is emitted for `_objc_msgSend`
- Stubs are emitting pointing to the synthesized locations

Notes:

- Both `__objc_methname` and `__objc_selrefs` can also exist from object
  files, so their contents are merged with our synthesized contents
- The compiler emits method names for defined methods, but not for
  undefined symbols you call, but stubs are used for both
- This only implements the default "fast" mode currently just to reduce
  the diff, I also doubt many folks will care to swap modes
- This only implements this for arm64 and x86_64, we don't need to
  implement this for 32 bit iOS archs, but we should implement it for
  watchOS archs in a later diff

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

getnetent is availible from API 28

This fixes the stand-alone build configuration where LLVM_MAIN_SRC_DIR
does not exist.

Reviewed By: JDevlieghere

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

This change inlines DOT_PRODUCT calls for real and integer types.

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

This patch introduces a new option to the crashlog command to get the
the script version.

Since `crashlog.py` is not actually versioned, this returns lldb's
version instead.

rdar://98392669

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



Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>

Supposedly our ABI issues were fixed, per issue:
https://github.com/llvm/llvm-project/issues/55992

However, with a recent changes to bf16, these tests
fail again; not sure why yet:
https://reviews.llvm.org/D130832
https://lab.llvm.org/buildbot/#/builders/61/builds/30600

So we disable the tests for now. Issue is tracked in:
https://github.com/llvm/llvm-project/issues/57042

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

This work is being done to reduce the size of MSAN with track origins binary.

Builds upon: https://reviews.llvm.org/D131205

Reviewed By: vitalybuka

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

Remove unreachable code that will never execute.

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

Static code inspection guided fixes for the following issues:
- dead code
- buffer not null-terminated
- null-dereference
- out-of-bounds access

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

The functions converting integers into decimal, hexadecimal, and octal,
are all very similar. This patch moves to a combined converter to save
code size.

Reviewed By: sivachandra

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

Reviewed By: sivachandra

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

Use of uninitialized memory.
https://lab.llvm.org/buildbot/#/builders/74/builds/12713

This reverts commit 8a4c40bf.

https://lab.llvm.org/buildbot/#/builders/74/builds/12713

This reverts commit 000c8fef.

https://lab.llvm.org/buildbot/#/builders/74/builds/12713

This reverts commit 43b298ea.

If we collect potential values we need to visit a value even if we have
seen it before if the scope is different. The scope is part of the
result after all. Test included.

Fixes https://github.com/llvm/llvm-project/issues/56753

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

Like D131405, but for ELF.

No behavior change.

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

Reviewed By: ktras

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

Replace a switch statement used to validate arguments to known library
functions with a more consistent table-driven approach and tighten it
up.

Reviewed By: sivachandra

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

When clang includes a PCH, it tolerates some amount of differences
between the defines used when creating and when including the PCH
- this seems to be intentionally allowed in
c379c072 (and later extended in
b6368751).

When using a PCH (or when picking a PCH out of a directory containing
multiple candidates) Clang used to accept the header if there were
defines on the command line when creating the PCH that are missing
when using the PCH, or vice versa, defines only set when using the
PCH.

The only cases where Clang explicitly rejected the use of a PCH
is if there was an explicit conflict between the options, e.g.
-DFOO=1 vs -DFOO=2, or -DFOO vs -UFOO.

The latter commit added a FIXME that we really should check whether
mismatched defines actually were used somewhere in the PCH, so that
the define would affect the outcome. This FIXME has stood unaddressed
since 2012.

This differs from GCC, which rejects PCH files if the defines differ
at all.

When explicitly including a single PCH file, the relaxed policy
of allowing minor differences is harmless for correct use cases
(but may fail to diagnose mismtaches), and potentially allow using
PCHs in wider cases (where the user intentionally know that the
differences in defines are harmless for the PCH).

However, for GCC style PCH directories, with a directory containing
multiple PCH variants and the compiler should pick the correct match
out of them, Clang's relaxed logic was problematic. The directory
could contain two otherwise identical PCHs, but one built with -DFOO
and one without. When attempting to include a PCH and iterating over
the candidates in the directory, Clang would essentially pick the
first one out of the two, even if there existed a better, exact
match in the directory.

Keep the relaxed checking when specificlly including one named
PCH file, but require strict matches when trying to pick the right
candidate out of a GCC style directory with alternatives.

This fixes https://github.com/lhmouse/mcfgthread/issues/63.

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

As discussed in the post-commit feedback for b53d44fe,
this test was failing on AIX because atan(-0.0) results in 0.0 (positive).

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

Since D129389 (and downstream PR https://github.com/apple/llvm-project/pull/4965), the dependency scanner is responsible for generating full command-lines, including the modules paths. This patch removes the flag that was making this an opt-in behavior in clang-scan-deps.

Reviewed By: benlangmuir

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

So far, the `thread::id` comparators were implemented as hidden friends.
This was non-conforming and lead to incorrectly rejected C++ code, as
can be seen in the linked Github issue.

Fixes https://github.com/llvm/llvm-project/issues/56187

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

Breaks ASan tests.

This reverts commit 3f8ae7ef.