This should address build failures found in:

https://lab.llvm.org/buildbot/#/builders/217/builds/3610
https://lab.llvm.org/buildbot/#/builders/215/builds/4609
https://lab.llvm.org/buildbot/#/builders/68/builds/31012

This reverts commit be0905a3.
This patch broke build addressed in https://github.com/llvm/llvm-project/issues/54968


Signed-off-by: Jun Zhang <jun@junz.org>

Fixes a crash introduced in D123737 where LastNonComment would be null.

Reviewed By: curdeius

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

POSIX locking and unlocking functions flockfile and funlockfile have
also been added. The locking is not recursive yet. A future patch will
make the underlying lock a recursive lock.

Reviewed By: lntue

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

As a project, Clang has gotten negative public feedback about our lack
of communicating changes to users. There are comments on places like
Hacker News or Reddit where users have (rightfully) been confused as to
what changes happen in a given release, leading to misinformation like
Clang not adding support for C++20 features:
https://news.ycombinator.com/item?id=28761464.

This documents the expectation that changes which impact users should
have release notes, and it's normal for code reviewers to ask an author
to add a release note for a given change.

This addresses: https://github.com/llvm/llvm-project/issues/54965

RFC: https://discourse.llvm.org/t/rfc-update-developer-policy-on-release-notes/61856

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

Rename classes Assemble -> Assembler, Link -> Linker,
for consistency with names other toolchains use.

Reviewed By: lntue

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

C89 had a questionable feature where the compiler would implicitly
declare a function that the user called but was never previously
declared. The resulting function would be globally declared as
extern int func(); -- a function without a prototype which accepts zero
or more arguments.

C99 removed support for this questionable feature due to severe
security concerns. However, there was no deprecation period; C89 had
the feature, C99 didn't. So Clang (and GCC) both supported the
functionality as an extension in C99 and later modes.

C2x no longer supports that function signature as it now requires all
functions to have a prototype, and given the known security issues with
the feature, continuing to support it as an extension is not tenable.

This patch changes the diagnostic behavior for the
-Wimplicit-function-declaration warning group depending on the language
mode in effect. We continue to warn by default in C89 mode (due to the
feature being dangerous to use). However, because this feature will not
be supported in C2x mode, we've diagnosed it as being invalid for so
long, the security concerns with the feature, and the trivial
workaround for users (declare the function), we now default the
extension warning to an error in C99-C17 mode. This still gives users
an easy workaround if they are extensively using the extension in those
modes (they can disable the warning or use -Wno-error to downgrade the
error), but the new diagnostic makes it more clear that this feature is
not supported and should be avoided. In C2x mode, we no longer allow an
implicit function to be defined and treat the situation the same as any
other lookup failure.

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

This is not expected to have a functional difference as discussed in the
post-commit comments for 8a9c70fc. All of the motivating tests for
the older fold still optimize as expected because other code can infer
the 'nuw'.

This was tracking global state only used by the AsmPrinter, which can
store its own module global state.

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

Reviewed By: aaron.ballman

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

This is x86 specific, and adds statefulness to
MachineModuleInfo. Instead of explicitly tracking this, infer if we
need to declare the symbol based on the reference previously inserted.

This produces a small change in the output due to the move from
AsmPrinter::doFinalization to X86's emitEndOfAsmFile. This will now be
moved relative to other end of file fields, which I'm assuming doesn't
matter (e.g. the __morestack_addr declaration is now after the
.note.GNU-split-stack part)

This also produces another small change in code if the module happened
to define/declare __morestack_addr, but I assume that's invalid and
doesn't really matter.

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

Reviewed By: Sockke

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

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

Reviewed By: whisperity, aaron.ballman

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

This is used to emit one field in doFinalization for the module. We
can accumulate this when emitting all individual functions directly in
the AsmPrinter, rather than accumulating additional state in
MachineModuleInfo.

Move the special case behavior predicate into MachineFrameInfo to
share it. This now promotes it to generic behavior. I'm assuming this
is fine because no other target implements adjustForSegmentedStacks,
or has tests using the split-stack attribute.

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

BlockIsSimpleEnoughToThreadThrough() already checks that the phi
(and all other instructions) are not used outside the block, so
this one-use check is not necessary for legality. I also don't
see any reason why it would be necessary for profitability (in
fact, those extra uses will be replaced with constants, which
should be generally profitable).

getSuccProbability was private for some reason, saying to go through
MachineBranchProbabilityInfo. There doesn't seem to be much point to
that, as that wrapper directly calls this.

Like other areas, some of these fields aren't handled by the MIR
printer/parser so aren't tested.

When folding a COPY of exec into another COPY, the call to
TII->isOperandLegal would crash because COPYs don't have defined
register classes for their operands.

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

The checkBuiltinArgument helper takes an integer ArgIndex and is
documented as performing normal type-checking on that argument. However,
it mistakenly hardcodes the argument index to zero when retrieving the
argument from the call expression.

This hadn't been noticed previously as all in-tree uses typecheck the
0th argument anyway.

Add supports in FindTarget and IncludeCleaner. This would
improve AST-based features on a tempalte which is found via a using
declaration. For example, go-to-def on `vect^or<int> v;` gives us the
location of `using std::vector`, which was not previously.

Base on https://reviews.llvm.org/D123127

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

This reverts commit 2f49163b to fix
a buildbot failure. Reported in https://lab.llvm.org/buildbot#builders/105/builds/24284

D119136 changed how captures are handled in a lambda call operator
declaration, but did not properly handled dependant context,
which led to crash when refering to init-captures in
a trailing return type.

We fix that bug by making transformations more symetric with parsing,
ie. we first create the call operator, then transform the capture,
then compute the type of the lambda call operaror.

This ensures captures exist and have the right type when
we parse a trailing requires-clause / return type.

Reviewed By: aaron.ballman

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

Like D118875, but for ubsan, asan, etc.

With this, I can successfully run:

    bin/clang++ -target x86_64-apple-ios14.0-macabi foo.cc \
        -isysroot $(xcrun -show-sdk-path) -fsanitize=undefined

with a locally built libclang_rt.ubsan_osx_dynamic.dylib.

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

Add a helper used to implement the build methods generated by ods-gen. The change reduces code size and compilation time since all structured op builders use the same build method. The change reduces the LinalgOps.cpp compilation time from 10.2s to 9.8s (debug build).

Depends On D123987

Reviewed By: nicolasvasilache

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

We add a new clang library called `clangSupport` for putting those utils which can be used in clang table-gen and other clang component.

We tried to put that into `llvm/Support`, but actually those stuffs only used in clang* and clang-tblgen, so I think that might be better to create `clang/Support`

* clang will used that in https://reviews.llvm.org/D111617.

Reviewed By: khchen, MaskRay, aaron.ballman

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

The revision avoids template methods for parsing and printing that are replicated for every named operation. Instead, the new methods take a regionBuilder argument. The revision reduces the compile time of LinalgOps.cpp from 11.2 to 10.2 seconds (debug build).

Reviewed By: nicolasvasilache

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

We can process the long shuffles (working across several actual
vector registers) in the best way if we take the actual register
represantion into account. We can build more correct representation of
register shuffles, improve number of recognised buildvector sequences.
Also, same function can be used to improve the cost model for the
shuffles. in future patches.

Part of D100486

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