Reviewers: djasper

Reviewed By: djasper

Subscribers: Eugene.Zelenko, klimek, cfe-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@299919 91177308-0d34-0410-b5e6-96231b3b80d8

It's used by MS headers in VS 2017 without including intrin.h, so we
can't implement it in the header anymore.

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@299782 91177308-0d34-0410-b5e6-96231b3b80d8

MSDN (https://msdn.microsoft.com/en-us/library/h5w10wxs.aspx) indicates
that `__declspec(naked)` is only permitted on x86 and ARM targets.
Testing with cl does confirm this behaviour.  Provide a warning for use
of `__declspec(naked)` on x64.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@299774 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@299760 91177308-0d34-0410-b5e6-96231b3b80d8

Hopefully fix crashes by unshadowing the variable.


Original commit message:

A big part of the clone detection code is functionality for filtering clones and
clone groups based on different criteria. So far this filtering process was
hardcoded into the CloneDetector class, which made it hard to understand and,
ultimately, to extend.

This patch splits the CloneDetector's logic into a sequence of reusable
constraints that are used for filtering clone groups. These constraints
can be turned on and off and reodreder at will, and new constraints are easy
to implement if necessary.

Unit tests are added for the new constraint interface.

This is a refactoring patch - no functional change intended.

Patch by Raphael Isemann!

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


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@299653 91177308-0d34-0410-b5e6-96231b3b80d8

rdar://20441985


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@299650 91177308-0d34-0410-b5e6-96231b3b80d8

lambda capture used by the created block

The commit r288866 introduced guaranteed copy elision to C++ 17. This
unfortunately broke the lambda to block conversion in C++17 (the compiler
crashes when performing IRGen). This commit fixes the conversion by avoiding
copy elision for the capture that captures the lambda that's used in the block
created by the lambda to block conversion process.

rdar://31385153

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


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@299646 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@299639 91177308-0d34-0410-b5e6-96231b3b80d8

clang-format <<END
auto c1 = u8'a';
auto c2 = u'a';
END

Before:
  auto c1 = u8 'a';
  auto c2 = u'a';

Now:
  auto c1 = u8'a';
  auto c2 = u'a';

Patch from Denis Gladkikh <llvm@denis.gladkikh.email>!


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@299574 91177308-0d34-0410-b5e6-96231b3b80d8

This reverts commit r299544.

Crashes on tests on some buildbots.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@299550 91177308-0d34-0410-b5e6-96231b3b80d8

A big part of the clone detection code is functionality for filtering clones and
clone groups based on different criteria. So far this filtering process was
hardcoded into the CloneDetector class, which made it hard to understand and,
ultimately, to extend.

This patch splits the CloneDetector's logic into a sequence of reusable
constraints that are used for filtering clone groups. These constraints
can be turned on and off and reodreder at will, and new constraints are easy
to implement if necessary.

Unit tests are added for the new constraint interface.

This is a refactoring patch - no functional change intended.

Patch by Raphael Isemann!

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


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@299544 91177308-0d34-0410-b5e6-96231b3b80d8

Summary:
I saw the same changes in the following review: https://reviews.llvm.org/D17438

I don't know in that way I could determine that atomic variable was initialized by macro ATOMIC_VAR_INIT. Anyway I added check that atomic variables can be initialize only in global scope.
I think that we can discuss this change.

Reviewers: Anastasia, cfe-commits

Reviewed By: Anastasia

Subscribers: bader, yaxunl

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@299537 91177308-0d34-0410-b5e6-96231b3b80d8

This patch adds the option -print-resource-dir. It simply
prints the resource directory. This information will eventually
be used in compiler-rt to setup COMPILER_RT_LIBRARY_INSTALL_DIR.

Patch by Catherine Moore!

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@299473 91177308-0d34-0410-b5e6-96231b3b80d8

This adds the new pragma and the first variant, contract(on/off/fast).

The pragma has the same block scope rules as STDC FP_CONTRACT, i.e. it can be
placed at the beginning of a compound statement or at file scope.

Similarly to STDC FP_CONTRACT there is no need to use attributes.  First an
annotate token is inserted with the parsed details of the pragma.  Then the
annotate token is parsed in the proper contexts and the Sema is updated with
the corresponding FPOptions using the shared ActOn function with STDC
FP_CONTRACT.

After this the FPOptions from the Sema is propagated into the AST expression
nodes.  There is no change here.

I was going to add a 'default' option besides 'on/off/fast' similar to STDC
FP_CONTRACT but then decided against it. I think that we'd have to make option
uppercase then to avoid using 'default' the keyword.  Also because of the
scoped activation of pragma I am not sure there is really a need a for this.

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@299470 91177308-0d34-0410-b5e6-96231b3b80d8

Summary: Implement new Z3 constraint manager backend.

Reviewers: zaks.anna, dcoughlin, NoQ, xazax.hun

Subscribers: mgorny, cfe-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@299463 91177308-0d34-0410-b5e6-96231b3b80d8

Summary: Preserve vec3 type with CodeGen option.

Reviewers: Anastasia, bruno

Reviewed By: Anastasia

Subscribers: bruno, ahatanak, cfe-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@299445 91177308-0d34-0410-b5e6-96231b3b80d8

Summary:
Certain implicitly generated coroutine statements, such as the calls to 'return_value()' or `return_void()` or `get_return_object_on_allocation_failure()`, cannot be built until the promise type is no longer dependent. This means they are not built until after the coroutine body statement has been transformed.

This patch fixes an issue where these statements would never be built for coroutine templates.

It also fixes a small issue where diagnostics about `get_return_object_on_allocation_failure()` were incorrectly suppressed. 

Reviewers: rsmith, majnemer, GorNishanov, aaron.ballman

Reviewed By: GorNishanov

Subscribers: cfe-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@299380 91177308-0d34-0410-b5e6-96231b3b80d8

Enhance -Wshadow to emit a warning when typedefs or type aliases are shadowed.

Fixes bug https://bugs.llvm.org//show_bug.cgi?id=28676.

Patch by Ahmed Asadi.

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


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@299363 91177308-0d34-0410-b5e6-96231b3b80d8

- also replace direct equality checks against the ConstantEvaluated enumerator  with isConstantEvaluted(), in anticipation of adding finer granularity to the various ConstantEvaluated contexts and reinstating certain restrictions on where lambda expressions can occur in C++17.

- update the clang tablegen backend that uses these Enumerators, and add the relevant scope where needed.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@299316 91177308-0d34-0410-b5e6-96231b3b80d8

This patch serializes the state of #pragma pack. It preserves the state of the
pragma from a PCH/from modules in a file that uses that PCH/those modules.

rdar://21359084

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


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@299226 91177308-0d34-0410-b5e6-96231b3b80d8

Also, while at it, s/IsCpp/isCpp/ so that it follows LLVM style.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@299214 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@299198 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@299193 91177308-0d34-0410-b5e6-96231b3b80d8

AddressSanitizer has an optional compile-time flag, -fsanitize-address-use-after-scope, which enables detection of use-after-scope bugs. We'd like to have this feature on by default, because it is already very well tested, it's used in several projects already (LLVM automatically enables it when using -DLLVM_USE_SANITIZER=Address), it's low overhead and there are no known issues or incompatibilities.

This patch enables use-after-scope by default via the Clang driver, where we set true as the default value for AsanUseAfterScope. This also causes the lifetime markers to be generated whenever fsanitize=address is used. This has some nice consequences, e.g. we now have line numbers for all local variables.

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



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@299174 91177308-0d34-0410-b5e6-96231b3b80d8

seems to be down.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@299151 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@299148 91177308-0d34-0410-b5e6-96231b3b80d8

GCC has the alloc_align attribute, which is similar to assume_aligned, except the attribute's parameter is the index of the integer parameter that needs aligning to.

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


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@299117 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@299083 91177308-0d34-0410-b5e6-96231b3b80d8

Reviewers: ioeric

Reviewed By: ioeric

Subscribers: alexshap, klimek, cfe-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@299073 91177308-0d34-0410-b5e6-96231b3b80d8

Fixes this clang warning on Windows:

warning: implicit truncation from 'clang::LangOptions::FPContractModeKind' to bit-field changes value from 2 to -2 [-Wbitfield-constant-conversion]
    fp_contract = LangOptions::FPC_Fast;
                ^ ~~~~~~~~~~~~~~~~~~~~~



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@299045 91177308-0d34-0410-b5e6-96231b3b80d8

Summary:
The -fxray-always-instrument= and -fxray-never-instrument= flags take
filenames that are used to imbue the XRay instrumentation attributes
using a whitelist mechanism (similar to the sanitizer special cases
list). We use the same syntax and semantics as the sanitizer blacklists
files in the implementation.

As implemented, we respect the attributes that are already defined in
the source file (i.e. those that have the
[[clang::xray_{always,never}_instrument]] attributes) before applying
the always/never instrument lists.

Reviewers: rsmith, chandlerc

Subscribers: jfb, mgorny, cfe-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@299041 91177308-0d34-0410-b5e6-96231b3b80d8

FPContractModeKind is the codegen option flag which is already ternary (off,
on, fast).  This makes it universally the type for the contractable info
across the front-end:

* In FPOptions (i.e. in the Sema + in the expression nodes).
* In LangOpts::DefaultFPContractMode which is the option that initializes
FPOptions in the Sema.

Another way to look at this change is that before fp-contractable on/off were
the only states handled to the front-end:
 * For "on", FMA folding was performed by  the front-end
 * For "fast", we simply forwarded the flag to TargetOptions to handle it in
 LLVM

Now off/on/fast are all exposed because for fast we will generate
fast-math-flags during CodeGen.

This is toward moving fp-contraction=fast from an LLVM TargetOption to a
FastMathFlag in order to fix PR25721.

---
This is a recommit of r299027 with an adjustment to the test
CodeGenCUDA/fp-contract.cu.  The test assumed that even
though -ffp-contract=on is passed FE-based folding of FMA won't happen.

This is obviously wrong since the user is asking for this explicitly with the
option.  CUDA is different that -ffp-contract=fast is on by default.

The test used to "work" because contract=fast and contract=on were maintained
separately and we didn't fold in the FE because contract=fast was on due to
the target-default.  This patch consolidates the contract=on/fast/off state
into a ternary state hence the change in behavior.
---

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@299033 91177308-0d34-0410-b5e6-96231b3b80d8

This reverts commit r299027.

It's causing a test failure in clang's CodeGenCUDE/fp-contract.cu

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@299029 91177308-0d34-0410-b5e6-96231b3b80d8

FPContractModeKind is the codegen option flag which is already ternary (off,
on, fast).  This makes it universally the type for the contractable info
across the front-end:

* In FPOptions (i.e. in the Sema + in the expression nodes).
* In LangOpts::DefaultFPContractMode which is the option that initializes
FPOptions in the Sema.

Another way to look at this change is that before fp-contractable on/off were
the only states handled to the front-end:
 * For "on", FMA folding was performed by  the front-end
 * For "fast", we simply forwarded the flag to TargetOptions to handle it in
 LLVM

Now off/on/fast are all exposed because for fast we will generate
fast-math-flags during CodeGen.

This is toward moving fp-contraction=fast from an LLVM TargetOption to a
FastMathFlag in order to fix PR25721.

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@299027 91177308-0d34-0410-b5e6-96231b3b80d8

Summary: clang should produce the same errors Objective-C classes that cannot be assigned to weak pointers under both -fobjc-arc and -fobjc-weak. Check for ObjCWeak along with ObjCAutoRefCount when analyzing pointer conversions. Add an -fobjc-weak pass to the existing arc-unavailable-for-weakref test cases to verify the behavior is the same.

Reviewers: rsmith, doug.gregor, rjmccall

Reviewed By: rjmccall

Subscribers: cfe-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@299014 91177308-0d34-0410-b5e6-96231b3b80d8

Summary: -Warc-repeated-use-of-weak should produce the same warnings with -fobjc-weak as it does with -objc-arc. Also check for ObjCWeak along with ObjCAutoRefCount when recording the use of an evaluated weak variable. Add a -fobjc-weak run to the existing arc-repeated-weak test case and adapt it slightly to work in both modes.

Reviewers: rsmith, doug.gregor, jordan_rose, rjmccall

Reviewed By: rjmccall

Subscribers: arphaman, rjmccall, cfe-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@299011 91177308-0d34-0410-b5e6-96231b3b80d8

Summary:
When a PCH is included via -include-pch, clang should treat the
current TU as dependent on the sourcefile that the PCH was generated from.

This is currently _partly_ accomplished by InitializePreprocessor calling
AddImplicitIncludePCH to synthesize an implicit #include of the sourcefile,
into the preprocessor's Predefines buffer.

For FrontendActions such as PreprocessOnlyAction (which is, curiously, what the
driver winds up running one of in response to a plain clang -M) this is
sufficient: the preprocessor cranks over its Predefines and emits a dependency
reference to the initial sourcefile.

For other FrontendActions (for example -emit-obj or -fsyntax-only) the
Predefines buffer is reset to the suggested predefines buffer from the PCH, so
the dependency edge is lost. The result is that clang emits a .d file in those
cases that lacks a reference to the .h file responsible for the input (and in
Swift's case, our .swiftdeps file winds up not including a reference to the
source file for a PCH bridging header.)

This patch fixes the problem by taking a different tack: ignoring the
Predefines buffer (which seems a bit like a hack anyways) and directly
attaching the CompilerInstance's DependencyCollectors (and legacy
DependencyFileGenerator) to the ASTReader for the external AST.

This approach is similar to the one chosen in earlier consultation with Bruno
and Ben, and I think it's the least-bad solution, given several options.

Reviewers: bruno, benlangmuir, doug.gregor

Reviewed By: bruno, doug.gregor

Subscribers: cfe-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@299009 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@298992 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@298978 91177308-0d34-0410-b5e6-96231b3b80d8

Reviewers: cfe-commits, Anastasia

Reviewed By: Anastasia

Subscribers: yaxunl, bader

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@298976 91177308-0d34-0410-b5e6-96231b3b80d8