Commit Graph

24216 Commits

Author SHA1 Message Date
Kristof Umann 204bf2bbb2 [analyzer] Add CheckerManager::getChecker, make sure that a registry function registers no more than 1 checker
This patch effectively fixes the almost decade old checker naming issue.
The solution is to assert when CheckerManager::getChecker is called on an
unregistered checker, and assert when CheckerManager::registerChecker is called
on a checker that is already registered.

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

llvm-svn: 352292
2019-01-26 21:41:50 +00:00
Kristof Umann 8fd74ebfc0 [analyzer] Reimplement dependencies between checkers
Unfortunately, up until now, the fact that certain checkers depended on one
another was known, but how these actually unfolded was hidden deep within the
implementation. For example, many checkers (like RetainCount, Malloc or CString)
modelled a certain functionality, and exposed certain reportable bug types to
the user. For example, while MallocChecker models many many different types of
memory handling, the actual "unix.MallocChecker" checker the user was exposed to
was merely and option to this modeling part.

Other than this being an ugly mess, this issue made resolving the checker naming
issue almost impossible. (The checker naming issue being that if a checker
registered more than one checker within its registry function, both checker
object recieved the same name) Also, if the user explicitly disabled a checker
that was a dependency of another that _was_ explicitly enabled, it implicitly,
without "telling" the user, reenabled it.

Clearly, changing this to a well structured, declarative form, where the
handling of dependencies are done on a higher level is very much preferred.

This patch, among the detailed things later, makes checkers declare their
dependencies within the TableGen file Checkers.td, and exposes the same
functionality to plugins and statically linked non-generated checkers through
CheckerRegistry::addDependency. CheckerRegistry now resolves these dependencies,
makes sure that checkers are added to CheckerManager in the correct order,
and makes sure that if a dependency is disabled, so will be every checker that
depends on it.

In detail:

* Add a new field to the Checker class in CheckerBase.td called Dependencies,
which is a list of Checkers.
* Move unix checkers before cplusplus, as there is no forward declaration in
tblgen :/
* Add the following new checkers:
  - StackAddrEscapeBase
  - StackAddrEscapeBase
  - CStringModeling
  - DynamicMemoryModeling (base of the MallocChecker family)
  - IteratorModeling (base of the IteratorChecker family)
  - ValistBase
  - SecuritySyntaxChecker (base of bcmp, bcopy, etc...)
  - NSOrCFErrorDerefChecker (base of NSErrorChecker and  CFErrorChecker)
  - IvarInvalidationModeling (base of IvarInvalidation checker family)
  - RetainCountBase (base of RetainCount and OSObjectRetainCount)
* Clear up and registry functions in MallocChecker, happily remove old FIXMEs.
* Add a new addDependency function to CheckerRegistry.
* Neatly format RUN lines in files I looked at while debugging.

Big thanks to Artem Degrachev for all the guidance through this project!

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

llvm-svn: 352287
2019-01-26 20:06:54 +00:00
Kristof Umann 98217adb87 [analyzer] Fix an bug where statically linked, but not registered checkers weren't recognized
My last patch, D56989, moved the validation of whether a checker exists into
its constructor, but we do support statically linked (and non-plugin) checkers
that were do not have an entry in Checkers.td. However, the handling of this
happens after the creation of the CheckerRegistry object.

This patch fixes this bug by moving even this functionality into
CheckerRegistry's constructor.

llvm-svn: 352284
2019-01-26 17:27:40 +00:00
Kristof Umann 3daa245550 [analyzer][NFC] Keep track of whether enabling a checker was explictly specified in command line arguments
I added a new enum to CheckerInfo, so we can easily track whether the check is
explicitly enabled, explicitly disabled, or isn't specified in this regard.
Checkers belonging in the latter category may be implicitly enabled through
dependencies in the followup patch. I also made sure that this is done within
CheckerRegisty's constructor, leading to very significant simplifications in
its query-like methods.

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

llvm-svn: 352282
2019-01-26 16:35:33 +00:00
Kristof Umann dd9c86e5ba [analyzer][NFC] Supply CheckerRegistry with AnalyzerOptions
Since pretty much all methods of CheckerRegistry has AnalyzerOptions as an
argument, it makes sense to just simply require it in it's constructor.

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

llvm-svn: 352279
2019-01-26 15:59:21 +00:00
Kristof Umann 058a7a450a [analyzer] Supply all checkers with a shouldRegister function
Introduce the boolean ento::shouldRegister##CHECKERNAME(const LangOptions &LO)
function very similarly to ento::register##CHECKERNAME. This will force every
checker to implement this function, but maybe it isn't that bad: I saw a lot of
ObjC or C++ specific checkers that should probably not register themselves based
on some LangOptions (mine too), but they do anyways.

A big benefit of this is that all registry functions now register their checker,
once it is called, registration is guaranteed.

This patch is a part of a greater effort to reinvent checker registration, more
info here: D54438#1315953

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

llvm-svn: 352277
2019-01-26 14:23:08 +00:00
Bruno Ricci db07683d86 [AST] Pack GenericSelectionExpr
Store the controlling expression, the association expressions and the
corresponding TypeSourceInfos as trailing objects.

Additionally use the bit-fields of Stmt to store one SourceLocation,
saving one additional pointer. This saves 3 pointers in total per
GenericSelectionExpr.

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

Reviewed By: aaron.ballman

Reviewers: aaron.ballman, steveire
llvm-svn: 352276
2019-01-26 14:15:10 +00:00
Bruno Ricci 94498c70ae [AST][NFC] Various cleanups to GenericSelectionExpr
Various cleanups to GenericSelectionExpr factored out of D57104. In particular:

1. Move the friend declaration to the top.
2. Introduce a constant ResultDependentIndex instead of the magic "-1".
3. clang-format
4. Group the member function together so that they can be removed as one block
   by D57106.

NFC.

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

Reviewed By: aaron.ballman

llvm-svn: 352275
2019-01-26 13:58:15 +00:00
Erik Pilkington 8bed74ba51 [Sema] Improve a -Warray-bounds diagnostic
Fix a bug where we would compare array sizes with incompatible
element types, and look through explicit casts.

rdar://44800168

Differential revision: https://reviews.llvm.org/D57064

llvm-svn: 352239
2019-01-25 20:52:45 +00:00
Erich Keane 1d1d438e8e Disable _Float16 for non ARM/SPIR Targets
As Discussed here:
http://lists.llvm.org/pipermail/llvm-dev/2019-January/129543.html

There are problems exposing the _Float16 type on architectures that
haven't defined the ABI/ISel for the type yet, so we're temporarily
disabling the type and making it opt-in.

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

Change-Id: I5db7366dedf1deb9485adb8948b1deb7e612a736
llvm-svn: 352221
2019-01-25 17:27:57 +00:00
Erich Keane 3e7fda229d Allow 'static' storage specifier on an out-of-line member function template
declaration in MSVCCompat mode

Microsoft compiler permits the use of 'static' storage specifier outside
of a class definition if it's on an out-of-line member function template
declaration.

This patch allows 'static' storage specifier on an out-of-line member
function template declaration with a warning in Clang (To be compatible
with Microsoft).

Intel C/C++ compiler allows the 'static' keyword with a warning in
Microsoft mode. GCC allows this with -fpermissive.

Patch By: Manna

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

Change-Id: I97b2d9e9d57cecbcd545d17e2523142a85ca2702
llvm-svn: 352219
2019-01-25 17:01:42 +00:00
Craig Topper 8de5abc4c8 [X86] Remove mask and passthru arguments from vpconflict builtins. Use select in IR instead.
llvm-svn: 352173
2019-01-25 07:08:22 +00:00
Petr Hosek 63bd4e9cd1 Revert "[AArch64] Use LL for 64-bit intrinsic arguments"
This reverts commit r351740: this broke on platforms where unsigned long
long isn't the same as uint64_t which is what ACLE specifies for the
return value of rsr64.

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

llvm-svn: 352153
2019-01-25 02:16:29 +00:00
George Karpenkov 6fdd2bd503 [analyzer] Port RetainSummaryManager to the new AnyCall interface, decouple ARCMT from the analyzer
rdar://19694750

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

llvm-svn: 352149
2019-01-25 01:24:04 +00:00
George Karpenkov 7faa1de17d [analysis] Introduce an AnyCall helper class, for abstraction over different callables
A lot of code, particularly in the analyzer, has to perform a lot of
duplication to handle functions/ObjCMessages/destructors/constructors in
a generic setting.
The analyzer already has a CallEvent helper class abstracting over such
calls, but it's not always suitable, since it's tightly coupled to other
analyzer classes (ExplodedNode, ProgramState, etc.) and it's not always
possible to construct.

This change introduces a very simple, very lightweight helper class to
do simple generic operations over callables.

In future, parts of CallEvent could be changed to use this class to
avoid some duplication.

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

llvm-svn: 352148
2019-01-25 01:23:51 +00:00
George Karpenkov 42c9473ede [AST] Add a method to get a call type from an ObjCMessageExpr
Due to references, expression type does not always correspond to an
expected method return type (e.g. for a method returning int & the
expression type of the call would still be int).
We have a helper method for getting the expected type on CallExpr, but
not on ObjCMessageExpr.

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

llvm-svn: 352147
2019-01-25 01:23:37 +00:00
Reid Kleckner 7211c57175 [clang-cl] Ignore space-separated /AI arguments
The /AI flag is for #using directives, which I don't think we support.
This is consistent with how the /I flag is handled by MSVC.  Add a test
for it.

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

llvm-svn: 352119
2019-01-24 22:26:51 +00:00
Dan Gohman b432369f6b [WebAssembly] Add an import_module function attribute
This adds a C/C++ attribute which corresponds to the LLVM IR wasm-import-module
attribute. It allows code to specify an explicit import module.

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

llvm-svn: 352106
2019-01-24 21:08:30 +00:00
Alex Lorenz 3cfe9d5c22 Add a priority field to availability attributes to prioritize explicit
attributes from declaration over attributes from '#pragma clang attribute'

Before this commit users had an issue when using #pragma clang attribute with
availability attributes:

The explicit attribute that's specified next to the declaration is not
guaranteed to be preferred over the attribute specified in the pragma.

This commit fixes this by introducing a priority field to the availability
attribute to control how they're merged. Attributes with higher priority are
applied over attributes with lower priority for the same platform. The
implicitly inferred attributes are given the lower priority. This ensures that:

- explicit attributes are preferred over all other attributes.
- implicitly inferred attributes that are inferred from an explicit attribute
  are discarded if there's an explicit attribute or an attribute specified
  using a #pragma for the same platform.
- implicitly inferred attributes that are inferred from an attribute in the
  #pragma are not used if there's an explicit, explicit #pragma, or an
  implicit attribute inferred from an explicit attribute for the declaration.

This is the resulting ranking:

`platform availability > platform availability from pragma > inferred availability > inferred availability from pragma`

rdar://46390243

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

llvm-svn: 352084
2019-01-24 19:14:39 +00:00
Sam McCall fa36120682 [FileManager] Revert r347205 to avoid PCH file-descriptor leak.
Summary:
r347205 fixed a bug in FileManager: first calling
getFile(shouldOpen=false) and then getFile(shouldOpen=true) results in
the file not being open.

Unfortunately, some code was (inadvertently?) relying on this bug: when
building with a PCH, the file entries are obtained first by passing
shouldOpen=false, and then later shouldOpen=true, without any intention
of reading them. After r347205, they do get unneccesarily opened.
Aside from extra operations, this means they need to be closed. Normally
files are closed when their contents are read. As these files are never
read, they stay open until clang exits. On platforms with a low
open-files limit (e.g. Mac), this can lead to spurious file-not-found
errors when building large projects with PCH enabled, e.g.
  https://bugs.chromium.org/p/chromium/issues/detail?id=924225

Fixing the callsites to pass shouldOpen=false when the file won't be
read is not quite trivial (that info isn't available at the direct
callsite), and passing shouldOpen=false is a performance regression (it
results in open+fstat pairs being replaced by stat+open).

So an ideal fix is going to be a little risky and we need some fix soon
(especially for the llvm 8 branch).
The problem addressed by r347205 is rare and has only been observed in
clangd. It was present in llvm-7, so we can live with it for now.

Reviewers: bkramer, thakis

Subscribers: ilya-biryukov, ioeric, kadircet, cfe-commits

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

llvm-svn: 352079
2019-01-24 18:55:24 +00:00
Erich Keane 9f6045111a [CPU-Dispatch] Make pentium_iii_no_xmm_regs and pentium_iii alias.
I discovered that in ICC (where this list comes from), that the two
pentium_iii versions were actually identical despite the two different
names (despite them implying a difference). Because of this, they ended
up having identical manglings, which obviously caused problems when used
together.

This patch makes pentium_iii_no_xmm_regs an alias for pentium_iii so
that it can still be used, but has the same meaning as ICC. However, we
still prohibit using the two together which is different (albeit better)
behavior.

Change-Id: I4f3c9a47e48490c81525c8a3d23ed4201921b288
llvm-svn: 352054
2019-01-24 15:28:57 +00:00
Richard Smith 386a4b5c0a Improve diagnostic for -fvisibility mismatch between module/PCH build
and use.

llvm-svn: 352011
2019-01-24 02:41:46 +00:00
Leonard Chan 009f9e8231 [Sema] Fix Modified Type in address_space AttributedType
This is a fix for https://reviews.llvm.org/D51229 where we pass the
address_space qualified type as the modified type of an AttributedType. This
change now instead wraps the AttributedType with either the address_space
qualifier or a DependentAddressSpaceType.

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

llvm-svn: 351997
2019-01-24 00:11:35 +00:00
Aaron Ballman b0d74bfe81 Merge similar target diagnostics for interrupt attribute into one; NFC
Patch by Kristina Bessonova!

llvm-svn: 351969
2019-01-23 18:02:17 +00:00
Vladimir Stefanovic ad255c80e5 [mips] Replace help-text for '-m{no}-relax-pic-calls'. NFC
Thanks to Simon Dardis for the new text.

llvm-svn: 351889
2019-01-22 22:33:53 +00:00
George Karpenkov db0c66eeb0 [analyzer] Model another special-case kind of cast for OSObject RetainCountChecker
Differential Revision: https://reviews.llvm.org/D56951

llvm-svn: 351864
2019-01-22 19:50:47 +00:00
Anastasia Stulova 5cffa45401 [OpenCL] Allow address spaces as method qualifiers.
Methods can now be qualified with address spaces to prevent
undesirable conversions to generic or to provide custom 
implementation to be used if the object is located in certain
memory segments.

This commit extends parsing and standard C++ overloading to
work for an address space of a method (i.e. implicit 'this'
parameter).

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

llvm-svn: 351747
2019-01-21 16:01:38 +00:00
Sam Parker a96f8461e7 [AArch64] Use LL for 64-bit intrinsic arguments
The ACLE states that 64-bit crc32, wsr, rsr and rbit operands are
uint64_t so we should have the clang builtin match this description
- which is what we already do for AArch32.

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

llvm-svn: 351740
2019-01-21 11:01:05 +00:00
Serge Guelton be88539b85 Replace llvm::isPodLike<...> by llvm::is_trivially_copyable<...>
As noted in https://bugs.llvm.org/show_bug.cgi?id=36651, the specialization for
isPodLike<std::pair<...>> did not match the expectation of
std::is_trivially_copyable which makes the memcpy optimization invalid.

This patch renames the llvm::isPodLike trait into llvm::is_trivially_copyable.
Unfortunately std::is_trivially_copyable is not portable across compiler / STL
versions. So a portable version is provided too.

Note that the following specialization were invalid:

    std::pair<T0, T1>
    llvm::Optional<T>

Tests have been added to assert that former specialization are respected by the
standard usage of llvm::is_trivially_copyable, and that when a decent version
of std::is_trivially_copyable is available, llvm::is_trivially_copyable is
compared to std::is_trivially_copyable.

As of this patch, llvm::Optional is no longer considered trivially copyable,
even if T is. This is to be fixed in a later patch, as it has impact on a
long-running bug (see r347004)

Note that GCC warns about this UB, but this got silented by https://reviews.llvm.org/D50296.

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

llvm-svn: 351701
2019-01-20 21:19:56 +00:00
Craig Topper 9fddc3fd00 [X86] Remove the cvtuqq2ps256/cvtqq2ps256 mask builtins. Replace with uitofp/sitofp and select.
Reviewers: RKSimon, spatel

Reviewed By: RKSimon

Subscribers: kristina, cfe-commits

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

llvm-svn: 351694
2019-01-20 19:04:56 +00:00
Chandler Carruth 2946cd7010 Update the file headers across all of the LLVM projects in the monorepo
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
2019-01-19 08:50:56 +00:00
Johannes Doerfert ac991bbb44 Emit !callback metadata and introduce the callback attribute
With commit r351627, LLVM gained the ability to apply (existing) IPO
  optimizations on indirections through callbacks, or transitive calls.
  The general idea is that we use an abstraction to hide the middle man
  and represent the callback call in the context of the initial caller.
  It is described in more detail in the commit message of the LLVM patch
  r351627, the llvm::AbstractCallSite class description, and the
  language reference section on callback-metadata.

  This commit enables clang to emit !callback metadata that is
  understood by LLVM. It does so in three different cases:
    1) For known broker functions declarations that are directly
       generated, e.g., __kmpc_fork_call for the OpenMP pragma parallel.
    2) For known broker functions that are identified by their name and
       source location through the builtin detection, e.g.,
       pthread_create from the POSIX thread API.
    3) For user annotated functions that carry the "callback(callee, ...)"
       attribute. The attribute has to include the name, or index, of
       the callback callee and how the passed arguments can be
       identified (as many as the callback callee has). See the callback
       attribute documentation for detailed information.

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

llvm-svn: 351629
2019-01-19 05:36:54 +00:00
Leonard Chan d3f3e16293 [Fixed Point Arithmetic] Fixed Point Addition Constant Expression Evaluation
This patch includes logic for constant expression evaluation of fixed point additions.

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

llvm-svn: 351593
2019-01-18 21:04:25 +00:00
Vladimir Stefanovic 99113a0ccf [mips] Add '-mrelax-pic-calls', '-mno-relax-pic-calls'
These two options enable/disable emission of R_{MICRO}MIPS_JALR fixups along
with PIC calls. The linker may then try to turn PIC calls into direct jumps.
By default, these fixups do get emitted by the backend, use
'-mno-relax-pic-calls' to omit them.

Differential revision: https://reviews.llvm.org/D56878

llvm-svn: 351579
2019-01-18 19:54:51 +00:00
George Karpenkov 2c2d0b6e97 Revert "Fix failing MSan bots"
This reverts commit 2cedaaef383d8d6142046074ffebc2bb5a914778.

Revert with a fix.

llvm-svn: 351575
2019-01-18 19:24:55 +00:00
Zola Bridges 826ef59568 [clang][slh] add Clang attr no_speculative_load_hardening
Summary:
This attribute will allow users to opt specific functions out of
speculative load hardening. This compliments the Clang attribute
named speculative_load_hardening. When this attribute or the attribute
speculative_load_hardening is used in combination with the flags
-mno-speculative-load-hardening or -mspeculative-load-hardening,
the function level attribute will override the default during LLVM IR
generation. For example, in the case, where the flag opposes the
function attribute, the function attribute will take precendence.
The sticky inlining behavior of the speculative_load_hardening attribute
may cause a function with the no_speculative_load_hardening attribute
to be tagged with the speculative_load_hardening tag in
subsequent compiler phases which is desired behavior since the
speculative_load_hardening LLVM attribute is designed to be maximally
conservative.

If both attributes are specified for a function, then an error will be
thrown.

Reviewers: chandlerc, echristo, kristof.beyls, aaron.ballman

Subscribers: llvm-commits

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

llvm-svn: 351565
2019-01-18 17:20:46 +00:00
Kadir Cetinkaya 2eff821bbd [tooling] Add a new argument adjuster for deleting plugin related command line args
Summary:
Currently both clangd and clang-tidy makes use of this mechanism so
putting it into tooling so that all tools can make use of it.

Reviewers: ilya-biryukov, sammccall

Subscribers: ioeric, cfe-commits

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

llvm-svn: 351531
2019-01-18 09:00:31 +00:00
Vlad Tsyrklevich d5dd6a5fdd Fix failing MSan bots
Revert r351508-351514, this block of changes introduced a consistent
MSan failure on the sanitizer bots.

llvm-svn: 351528
2019-01-18 08:43:22 +00:00
George Karpenkov 0029c3b64c [analyzer] const-ify reference to bug type used in BugReporter
Differential Revision: https://reviews.llvm.org/D56885

llvm-svn: 351511
2019-01-18 03:13:14 +00:00
George Karpenkov 1aa2bf8ea4 [analyzer] Extend BugType constructor to accept "SuppressOnSink" as a parameter
Differential Revision: https://reviews.llvm.org/D56884

llvm-svn: 351510
2019-01-18 03:13:01 +00:00
George Karpenkov a0425f3a2f [analyzer] [RetainCountChecker] Smart pointer support.
rdar://47323216

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

llvm-svn: 351508
2019-01-18 03:12:35 +00:00
Artem Dergachev 2ed0e79bb8 [analyzer] Make sure base-region and its sub-regions are either all alive or all dead.
SymbolReaper now realizes that our liveness analysis isn't sharp enough
to discriminate between liveness of, say, variables and their fields.
Surprisingly, this didn't quite work before: having a variable live only
through Environment (eg., calling a C++ method on a local variable
as the last action ever performed on that variable) would not keep the
region value symbol of a field of that variable alive.

It would have been broken in the opposite direction as well, but both
Environment and RegionStore use the scanReachableSymbols mechanism for finding
live symbols regions within their values, and due to that they accidentally
end up marking the whole chain of super-regions as live when at least one
sub-region is known to be live.

It is now a direct responsibility of SymbolReaper to maintain this invariant,
and a unit test was added in order to make sure it stays that way.

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

rdar://problem/46914108

llvm-svn: 351499
2019-01-18 00:08:56 +00:00
Erich Keane 26e4cef093 Make integral-o-pointer conversions in SFINAE illegal.
As reported in PR40362, allowing the conversion from an integral to a
pointer type (despite being illegal in the C++ standard) will cause
surprsing results when testing for certain behaviors in SFINAE.  This
patch converts the error to a SFINAE Error and adds a test to ensure
that it is still a warning in non-SFINAE but an error in it.

Change-Id: I1f475637fa4d83217ae37dc6b5dbf653e118fae4
llvm-svn: 351495
2019-01-17 23:11:15 +00:00
Eric Fiselier 73b51ae160 Add -Wctad-maybe-unsupported to diagnose CTAD on types with no user defined deduction guides.
Summary:
Some style guides want to allow using CTAD only on types that "opt-in"; i.e. on types that are designed to support it and not just types that *happen* to work with it.

This patch implements the `-Wctad-maybe-unsupported` warning, which is off by default, which warns when CTAD is used on a type that does not define any deduction guides.

The following pattern can be used to suppress the warning in cases where the type intentionally doesn't define any deduction guides:

```
struct allow_ctad_t;

template <class T>
struct TestSuppression {
  TestSuppression(T) {}
};
TestSuppression(allow_ctad_t)->TestSuppression<void>; // guides with incomplete parameter types are never considered.
```

Reviewers: rsmith, james.dennett, gromer

Reviewed By: rsmith

Subscribers: jdennett, Quuxplusone, lebedev.ri, cfe-commits

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

llvm-svn: 351484
2019-01-17 21:44:24 +00:00
Aaron Ballman 65e96bdaca Revert r351209 (which was a revert of r350891) with a fix.
The test case had a parse error that was causing the condition string to be misreported. We now have better fallback code for error cases.

llvm-svn: 351470
2019-01-17 20:21:34 +00:00
Volodymyr Sapsai 4daffc176f [Frontend] Make WrapperFrontendAction call WrappedAction.PrepareToExecuteAction.
Fixes `-emit-header-module` when GenerateHeaderModuleAction is wrapped
by another frontend action.

rdar://problem/47302588

Reviewers: rsmith, arphaman

Reviewed By: arphaman

Subscribers: jkorous, dexonsmith, cfe-commits

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

llvm-svn: 351402
2019-01-17 00:20:43 +00:00
Craig Topper 931779761e Recommit r351160 "[X86] Make _xgetbv/_xsetbv on non-windows platforms"
V8 has been fixed now.

llvm-svn: 351391
2019-01-16 22:56:25 +00:00
Leonard Chan 86285d2e17 [Fixed Point Arithmetic] Add APFixedPoint to APValue
This adds APFixedPoint to the union of values that can be represented with an APValue.

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

llvm-svn: 351368
2019-01-16 18:53:05 +00:00
Leonard Chan 2044ac89aa [Fixed Point Arithmetic] Fixed Point Addition
This patch covers addition between fixed point types and other fixed point
types or integers, using the conversion rules described in 4.1.4 of N1169.

Usual arithmetic rules do not apply to binary operations when one of the
operands is a fixed point type, and the result of the operation must be
calculated with the full precision of the operands, so we should not perform
any casting to a common type.

This patch does not include constant expression evaluation for addition of
fixed point types. That will be addressed in another patch since I think this
one is already big enough.

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

llvm-svn: 351364
2019-01-16 18:13:59 +00:00
Anton Korobeynikov 383e827121 [MSP430] Improve support of 'interrupt' attribute
* Accept as an argument constants in range 0..63 (aligned with TI headers and linker scripts provided with TI GCC toolchain).
* Emit function attribute 'interrupt'='xx' instead of aliases (used in the backend to create a section for particular interrupt vector).
* Add more diagnostics.

Patch by Kristina Bessonova!

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

llvm-svn: 351344
2019-01-16 13:44:01 +00:00