Summary: This patch makes the Clang's DominatorTree use the new IsPostDom template argument for DominatorTreeBase.
Reviewers: dberlin, sanjoy, davide, grosser
Reviewed By: dberlin
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D35316
llvm-svn: 308041
C11 standard refers to the signed counterpart of the type size_t in
the paragraph 7.21.6.1 where it defines d, i, o, u, x, or x conversion specifiers
(in printf format string).
In Clang there is a FIXME (in lib/Analysis/PrintfFormatString.cpp) for this case
(which is not handled correctly at the moment).
This diff adds getSignedSizeType method to TargetInfo and exposes it
in ASTContext similarly to how it is done for getSizeType.
lib/Analysis/PrintfFormatString.cpp will be changed in a separate commit.
Differential revision: https://reviews.llvm.org/D35378
Test plan: make check-all
llvm-svn: 308037
This is the clang part, adding support for
void __builtin_HEXAGON_Y2_dccleana(void*);
void __builtin_HEXAGON_Y2_dccleaninva(void*);
void __builtin_HEXAGON_Y2_dcinva(void*);
void __builtin_HEXAGON_Y2_dczeroa(void*);
void __builtin_HEXAGON_Y4_l2fetch(void*, unsigned);
void __builtin_HEXAGON_Y5_l2fetch(void*, unsigned long long);
Requires r308032.
llvm-svn: 308035
Summary:
We need it in clangd for refactoring that replaces ASTUnit
with manual AST management.
Reviewers: akyrtzi, benlangmuir, arphaman, klimek
Reviewed By: arphaman
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D35405
llvm-svn: 308016
Summary:
To get properly integration Clang-Tidy with CLion IDE, next things were implemented:
1) Preserve `Message`, `FileOffset`, `FilePath` in the clang-tidy output.
2) Export all diagnostics, not just the ones with fixes
3) Test-cases
Reviewers: klimek, ilya-biryukov, alexfh
Reviewed By: alexfh
Subscribers: alexfh, JDevlieghere, mgorny, xazax.hun, cfe-commits, klimek
Tags: #clang-tools-extra
Patch by Vladimir Plyashkun!
Differential Revision: https://reviews.llvm.org/D34404
llvm-svn: 308014
The goal of this commit is to fix clang-format so it does not merge tokens when
using the alternative spelling keywords. (eg: "not foo" should not become "notfoo")
The problem is that Preprocessor::HandleIdentifier used to drop the identifier info
from the token for these keyword. This means the first condition of
TokenAnnotator::spaceRequiredBefore is not met. We could add explicit check for
the spelling in that condition, but I think it is better to keep the IdentifierInfo
and handle the operator keyword explicitly when needed. That actually leads to simpler
code, and probably slightly more efficient as well.
Another side effect of this change is that __identifier(and) will now work as
one would expect, removing a FIXME from the MicrosoftExtensions.cpp test
Differential Revision: https://reviews.llvm.org/D35172
llvm-svn: 308008
property and check for incompatible attributes
This commit changes the way ambiguous property synthesis (i.e. when synthesizing
a property that's declared in multiple protocols) is performed. Previously,
Clang synthesized the first property that was found. This lead to problems when
the property was synthesized in a class that conformed to two protocols that
declared that property and a second protocols had a 'readwrite' declaration -
the setter was not synthesized so the class didn't really conform to the second
protocol and user's code would crash at runtime when they would try to set the
property.
This commit ensures that a first readwrite property is selected. This is a
semantic change that changes users code in this manner:
```
@protocol P @property(readonly) int p; @end
@protocol P2 @property(readwrite) id p; @end
@interface I <P2> @end
@implementation I
@syntesize p; // Users previously got a warning here, and Clang synthesized
// readonly 'int p' here. Now Clang synthesizes readwrite 'id' p..
@end
```
To ensure that this change is safe, the warning about incompatible types is
promoted to an error when this kind of readonly/readwrite ambiguity is detected
in the @implementation. This will ensure that previous code that had this subtle
bug and ignored the warning now will fail to compile with an error, and users
should not get suprises at runtime once they resolve the error.
The commit also extends the ambiguity checker, and now it can detect conflicts
among the different property attributes. An error diagnostic is used for
conflicting attributes, to ensure that the user won't get "suprises" at runtime.
ProtocolPropertyMap is removed in favour of a a set + vector because the map's
order of iteration is non-deterministic, so it couldn't be used to select the
readwrite property.
rdar://31579994
Differential Revision: https://reviews.llvm.org/D35268
llvm-svn: 307903
a declaration at location and for class that searches for all occurrences of
a specific declaration
This commit uses a single RecursiveSymbolVisitor class for both
USRLocFindingASTVisitor and NamedDeclOccurrenceFindingVisitor to avoid duplicate
traversal code. It also traverses nested name specifier locs in the new class
and remove the separate matching step.
Differential Revision: https://reviews.llvm.org/D34949
llvm-svn: 307898
devirtualized.
The code to detect devirtualized calls is already in IRGen, so move the
code to lib/AST and make it a shared utility between Sema and IRGen.
This commit fixes a linkage error I was seeing when compiling the
following code:
$ cat test1.cpp
struct Base {
virtual void operator()() {}
};
template<class T>
struct Derived final : Base {
void operator()() override {}
};
Derived<int> *d;
int main() {
if (d)
(*d)();
return 0;
}
rdar://problem/33195657
Differential Revision: https://reviews.llvm.org/D34301
llvm-svn: 307883
This commit allows checking whether an enum declaration is scoped
through libclang and clang.cindex (Python).
Patch by Johann Klähn!
Differential Revision: https://reviews.llvm.org/D35187
llvm-svn: 307771
This commit allows checking whether an enum declaration is scoped
through libclang and clang.cindex (Python).
Differential Revision: https://reviews.llvm.org/D35187
llvm-svn: 307769
Summary:
This mimics the implementation for the implicit destructors. The
generation of this scope leaving elements is hidden behind
a flag to the CFGBuilder, thus it should not affect existing code.
Currently, I'm missing a test (it's implicitly tested by the clang-tidy
lifetime checker that I'm proposing).
I though about a test using debug.DumpCFG, but then I would
have to add an option to StaticAnalyzer/Core/AnalyzerOptions
to enable the scope leaving CFGElement,
which would only be useful to that particular test.
Any other ideas how I could make a test for this feature?
Reviewers: krememek, jordan_rose
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D15031
llvm-svn: 307759
Added checks for the reduction clauses in the taskloop directives:
1. Only addressable items must be used in reduction clauses.
2. Reduction clauses cannot be used with nogroup clauses.
llvm-svn: 307693
documentation.
Trying to match integerLiteral(-1) will silently fail, because an numeric
literal is always positive.
- Update the documentation to explain how to match negative numeric
literals.
- Add a unit test.
Differential Revision: https://reviews.llvm.org/D35196
llvm-svn: 307663
This is a follow up for one of
the previous diffs https://reviews.llvm.org/D32328.
getTypeSize and with getIntWidth are not equivalent for bool
(see https://clang.llvm.org/doxygen/ASTContext_8cpp_source.html#l08444),
this causes a number of issues
(for instance, if APint X representing a bool is created
with the wrong bit width then X is not comparable against Min/Max
(because of the different bit width), that results in crashes
(triggered asserts) inside assume* methods),
for examples see the newly added test cases.
Test plan: make check-all
Differential revision: https://reviews.llvm.org/D35041
llvm-svn: 307604
- eliminated error handling for the indirect CompilerInstance, which should
never generate an error as it is created;
- added a new test for direct importation; and
- removed an unused implementation of the CompleteType() API.
This brings clang-import-test.cpp and ExternalASTMerge.cpp back to 100%
coverage on all metrics measured by DLLVM_BUILD_INSTRUMENTED_COVERAGE.
Differential Revision: https://reviews.llvm.org/D35220
llvm-svn: 307600
Summary: We probably want to use this useful templates in other pieces of code (e.g. the one from D34329), so we should make this public.
Reviewers: NoQ
Reviewed By: NoQ
Subscribers: cfe-commits, xazax.hun, v.g.vassilev, johannes
Differential Revision: https://reviews.llvm.org/D34880
llvm-svn: 307501
Certain targets (e.g. amdgcn) require global variable to stay in global or constant address
space. In C or C++ global variables are emitted in the default (generic) address space.
This patch introduces virtual functions TargetCodeGenInfo::getGlobalVarAddressSpace
and TargetInfo::getConstantAddressSpace to handle this in a general approach.
It only affects IR generated for amdgcn target.
Differential Revision: https://reviews.llvm.org/D33842
llvm-svn: 307470
In addition to the formal linkage rules, the Modules TS includes cases where
internal-linkage symbols within a module interface unit can be referenced from
outside the module via exported inline functions / templates. We give such
declarations "module-internal linkage", which is formally internal linkage, but
results in an externally-visible symbol.
llvm-svn: 307434
requirements in protocol/class/category declarations
The unguarded availability warnings in the protocol requirements of a protocol
/class/category declaration can be avoided. This matches the behaviour of
Swift's diagnostics. The warnings for deprecated/unavailable protocols are
preserved.
rdar://33156429
Differential Revision: https://reviews.llvm.org/D35061
llvm-svn: 307368
Summary:
Most clang tools should ignore the -M
family of options because one wouldn't want them
to generate a new dependency (.d) file. However,
some tools may want this dependency file. This
patch creates a mechanism for them to do this.
This implementation just plumbs a boolean down
several layers of calls. Each of the modified calls
has several call sites, and so a single member
variable or new API entry point won't work.
An alternative would be to write a function to filter
the -M family of arguments out of CC1Args, and have
each caller call that function by hand before calling
newInvocation, Invocation::run, or buildAstFromCodeWithArgs.
This is a more complicated and error-prone solution.
Why burden all the callers to remember to use
this function?
But I could rewrite this patch to use that method if
that is deemed more appropriate.
Reviewers: klimek
Reviewed By: klimek
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D34304
llvm-svn: 307315
problems in testing, see comments in D34161 for some more details.
A fix is in progres in D35011, but a revert seems better now as the fix will
probably take some more time to land.
llvm-svn: 307277
Summary: Pass the type of the device offloading when building the tool chain for a particular target architecture. This is required when supporting multiple tool chains that target a single device type. In our particular use case, the OpenMP and CUDA tool chains will use the same ```addClangTargetOptions ``` method. This enables the reuse of common options and ensures control over options only supported by a particular tool chain.
Reviewers: arpith-jacob, caomhin, carlo.bertolli, ABataev, jlebar, hfinkel, tstellar, Hahnfeld
Reviewed By: hfinkel
Subscribers: jgravelle-google, aheejin, rengolin, jfb, dschuff, sbc100, cfe-commits
Differential Revision: https://reviews.llvm.org/D29647
llvm-svn: 307272
When enable_if disables a particular overload resolution candidate,
rummage through the enable_if condition to find the specific condition
that caused the failure. For example, if we have something like:
template<
typename Iter,
typename = std::enable_if_t<Random_access_iterator<Iter> &&
Comparable<Iterator_value_type<Iter>>>>
void mysort(Iter first, Iter last) {}
and we call "mysort" with "std::list<int>" iterators, we'll get a
diagnostic saying that the "Random_access_iterator<Iter>" requirement
failed. If we call "mysort" with
"std::vector<something_not_comparable>", we'll get a diagnostic saying
that the "Comparable<...>" requirement failed.
llvm-svn: 307196
These cases occur frequently for declarations in the global module (above the
module-declaration) in a Modules TS module interface. When we merge a
definition from another module into such a module-private definition, ensure
that we transitively make everything lexically within that definition visible
to that translation unit.
llvm-svn: 307129
-fslp-vectorize-aggressive and -fno-slp-vectorize-aggressive flags back
under this group and test for the warning. Document the future removal
in the ReleaseNotes.
Differential Revision: https://reviews.llvm.org/D34926
llvm-svn: 306965
Summary:
Changed EABIVersion type from string to llvm::EABI.
It seems it was just a typo and this is intended implementation.
Differential Revision: https://reviews.llvm.org/D34595
llvm-svn: 306953
Summary:
Un-revert https://reviews.llvm.org/D34868, but with a slight tweak to the
documentation to fix an error -- I had used the wrong syntax for a link.
llvm-svn: 306948
Summary:
Depends on https://reviews.llvm.org/D34867.
Add a Clang frontend option to enable optimization remark hotness
thresholds, which were added to LLVM in https://reviews.llvm.org/D34867.
This prevents diagnostics that do not meet a minimum hotness
threshold from being output. When generating optimization remarks for large
codebases with a ton of cold code paths, this option can be used
to limit the optimization remark output at a reasonable size.
Discussion of this change can be read here:
http://lists.llvm.org/pipermail/llvm-dev/2017-June/114377.html
Reviewers: anemet, davidxl, hfinkel
Reviewed By: anemet
Subscribers: fhahn, cfe-commits
Differential Revision: https://reviews.llvm.org/D34868
llvm-svn: 306945
the target is 32-bit.
The following changes are made to the driver since 32-bit apps do not
run on iOS 11 or later:
- If the deployment target is set explicitly, either with a command-line
option or an environment variable, the driver should report an error
if the version is greater than iOS 10.
- In the case where the deployment target is not set explicitly and the
default is inferred from the target triple or SDK version, it should
use a maximum default of iOS 10.99.99.
rdar://problem/32230613
Differential Revision: https://reviews.llvm.org/D34529
llvm-svn: 306922
Allow ODR for ObjC/C in the sense that we won't keep more that
one definition around (merge them). However, ensure the decl
pass the structural compatibility check in C11 6.2.7/1, for that,
reuse the structural equivalence checks used by the ASTImporter.
Few other considerations:
- Create error diagnostics for tag types mismatches and thread
them into the structural equivalence checks.
- Note that by doing this we only support redefinition between types
that are considered "compatible types" by C.
This is mixed approach of the suggestions discussed in
http://lists.llvm.org/pipermail/cfe-dev/2017-March/053257.html
Differential Revision: https://reviews.llvm.org/D31778
rdar://problem/31909368
llvm-svn: 306918
Redeclaration lookup should never find hidden enumerators in C, because
they do not have linkage (C11 6.2.2/6)
The linkage of an enumerator should be VisibleNoLinkage, and
isHiddenDeclarationVisible should be checking hasExternalFormalLinkage.
This is was reviewed as part of D31778, but splitted into a different
commit for clarity.
rdar://problem/31909368
llvm-svn: 306917
Summary:
This patch introduces a few extra BraceWrapping options, similar to
`SplitEmptyFunction`, to allow merging empty 'record' bodies (e.g.
class, struct, union and namespace):
* SplitEmptyClass
* SplitEmptyStruct
* SplitEmptyUnion
* SplitEmptyNamespace
The `SplitEmptyFunction` option name has also been simplified/
shortened (from `SplitEmptyFunctionBody`).
These options are helpful when the correspond AfterXXX option is
enabled, to allow merging the empty record:
class Foo
{};
In addition, this fixes an unexpected merging of short records, when
the AfterXXXX options are used, which caused to be formatted like
this:
class Foo
{ void Foo(); };
This is now properly formatted as:
class Foo
{
void Foo();
};
Reviewers: djasper, krasimir
Reviewed By: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D34395
llvm-svn: 306874
This is a more principled version of r303756. That change was both very
brittle about the state of the Diags object going into the driver and
also broke tooling in funny ways.
In particular it prevented tools from capturing diagnostics properly and
made the compilation database logic fail to provide arguments to the
tool, falling back to scanning directories for JSON files.
llvm-svn: 306822
basic block vectorizer. This vectorizer has had no known users for many,
many years and is completely surpassed by the normal
'-fvectorize-slp'-controlled SLP vectorizer in LLVM.
Hal proposed this back in 2014 to no objections:
http://lists.llvm.org/pipermail/llvm-dev/2014-November/079091.html
While this patch completely removes the flag, Joerg is working on
a patch that will add it back in a way that warns users and ignores the
flag in a clear and well factored way (so that we can keep doing this
going forward).
Differential Revision: https://reviews.llvm.org/D34846
llvm-svn: 306786
We use this when running a preprocessor-only action on an AST file in order to
avoid paying the runtime cost of loading the extra information.
llvm-svn: 306760
improve support for LLVM-style include sorting.
This really is a collection of improvements to the rules for LLVM
include sorting:
- We have gmock headers now, so it adds support for those to one of the
categories.
- LLVM does use 'FooTest.cpp' files to test 'Foo.h' so it adds that
suffix for finding a main header.
- At times the test file's case may not match the header file's case, so
switch to case-insensitive regex matching of header names.
With this set of changes, I can't spot any misbehaviors when re-sorting
all of LLVM's unittest '#include' lines.
Thanks to Eric and Daniel for help testing and refining the patch during
review!
Differential Revision: https://reviews.llvm.org/D33932
llvm-svn: 306759
a c++17 aligned allocation/deallocation function that is unavailable in
the standard library on Apple platforms.
The aligned functions are implemented only in the following versions or
later versions of the OSes, so clang issues diagnostics if the deployment
target being targeted is older than these:
macosx: 10.13
ios: 11.0
tvos: 11.0
watchos: 4.0
The diagnostics are issued whenever the aligned functions are selected
except when the selected function has a definition in the same file.
If there is a user-defined function available somewhere else, option
-Wno-aligned-allocation-unavailable can be used to silence the
diagnostics.
rdar://problem/32664169
Differential Revision: https://reviews.llvm.org/D34574
llvm-svn: 306722
The first user of this API will be the cross translation unit
functionality of the Static Analyzer which will be committed in a
follow-up patch.
Differential Revision: https://reviews.llvm.org/D34506
llvm-svn: 306648
Summary:
In change 2ba19793512, the ASTReader logic for ObjC interfaces was modified to
preserve the first definition-data read, "merging" later definitions into it
rather than overwriting it (though this "merging" is, in practice, a no-op that
discards the later definition-data).
Unfortunately this change was only made to ObjC interfaces, not protocols; this
means that when (for example) loading a protocol that references an interface,
if both the protocol and interface are multiply defined (as can easily happen
if the same header is read from multiple contexts), an _inconsistent_ pair of
definitions is loaded: first-read for the interface and last-read for the
protocol.
This in turn causes very subtle downstream bugs in the Swift ClangImporter,
which filters the results of name lookups based on the owning module of a
definition; inconsistency between a pair of related definitions causes name
lookup failures at various stages of compilation.
To fix these downstream issues, this change replicates the logic applied to
interfaces in change 2ba19793512, but for ObjC protocols.
rdar://30851899
Reviewers: doug.gregor, rsmith
Reviewed By: doug.gregor
Subscribers: jordan_rose, cfe-commits
Differential Revision: https://reviews.llvm.org/D34741
llvm-svn: 306583
Summary: It used to always call into the RealFileSystem before.
Reviewers: bkramer, krasimir, klimek, bruno
Reviewed By: klimek
Subscribers: bruno, cfe-commits
Differential Revision: https://reviews.llvm.org/D34469
llvm-svn: 306549
Summary: This patch exposes the exception specification type (noexcept,
etc.) of a C++ function through libclang and Python clang.cindex.
Reviewers: rsmith, aaron.ballman
Reviewed By: aaron.ballman
Subscribers: jbcoe, cfe-commits
Differential Revision: https://reviews.llvm.org/D34091
Patch by Andrew Bennieston
llvm-svn: 306483
This patch extends the `overloadable` attribute to allow for one
function with a given name to not be marked with the `overloadable`
attribute. The overload without the `overloadable` attribute will not
have its name mangled.
So, the following code is now legal:
void foo(void) __attribute__((overloadable));
void foo(int);
void foo(float) __attribute__((overloadable));
In addition, this patch fixes a bug where we'd accept code with
`__attribute__((overloadable))` inconsistently applied. In other words,
we used to accept:
void foo(void);
void foo(void) __attribute__((overloadable));
But we will do this no longer, since it defeats the original purpose of
requiring `__attribute__((overloadable))` on all redeclarations of a
function.
This breakage seems to not be an issue in practice, since the only code
I could find that had this pattern often looked like:
void foo(void);
void foo(void) __attribute__((overloadable)) __asm__("foo");
void foo(int) __attribute__((overloadable));
...Which can now be simplified by simply removing the asm label and
overloadable attribute from the redeclaration of `void foo(void);`
Differential Revision: https://reviews.llvm.org/D32332
llvm-svn: 306467
This is a new checker package. It contains checkers that highlight
well-documented implementation-defined behavior. Such checkers are only useful
to developers that intend to write portable code. Code that is only compiled for
a single platform should be allowed to rely on this platform's specific
documented behavior.
rdar://problem/30545046
Differential Revision: https://reviews.llvm.org/D34102
llvm-svn: 306396
This reverts commit r305688 meaning it reintroduces r305684. To repeat:
[NFC] Refactor DiagnosticRenderer to use FullSourceLoc
Move the DiagnosticRenderer and its dependents to using FullSourceLocs
instead of a SourceLocation and SourceManager pointer. The changeset is
rather large but entirely mechanical.
This is step one to allow DiagnosticRenderer to take either
llvm::SMLocs or clang::SourceLocations.
This breaks clang-tidy and clng-query which will be fixed in a commit
soon after.
Patch by Sanne Wouda
Differential Revision: https://reviews.llvm.org/D31709
llvm-svn: 306384
... once each for the syntactic and semantic form. Without this fix, behavior
of the newly added tests would have been
InitListExprIsPreOrderVisitedTwice:
syntactic: 1
semantic: 2
InitListExprIsPostOrderVisitedTwice:
syntactic: 0
semantic: 1
InitListExprIsPreOrderNoQueueVisitedTwice:
syntactic: 1
semantic: 2
InitListExprIsPostOrderNoQueueVisitedTwice:
syntactic: 0
semantic: 2
llvm-svn: 306374
According to the documentation, when encoding a bit-field, GNU runtime
needs its starting position in addition to its type and size.
https://gcc.gnu.org/onlinedocs/gcc/Type-encoding.html
Prior to r297702, the starting position information was not being
encoded, which is incorrect, and after r297702, an assertion started to
fail because an ObjCIvarDecl was being passed to a function expecting a
FieldDecl.
This commit moves LookupFieldBitOffset to ASTContext and uses the
function to encode the starting position of bit-fields.
llvm-svn: 306364
Also add testcases for a bunch of expression forms that cause our evaluator to
crash. See PR33140 and PR32864 for crashes that this was causing.
This reverts r305287, which reverted r305239, which reverted r301742. The
previous revert claimed that buildbots were broken, but did not add any
testcases and the buildbots have lost all memory of what was wrong here.
Changes to test/OpenMP are not reverted; another change has triggered those
tests to change their output in the same way that r301742 did.
llvm-svn: 306346
definition or non-reference class type.
The crash occurs when there is a template parameter list in a class that
is missing the closing angle bracket followed by a definition of a
struct. For example:
class C0 {
public:
template<typename T, typename T1 = T // missing closing angle bracket
struct S0 {};
C0() : m(new S0<int>) {}
S0<int> *m;
};
This happens because the parsed struct is added to the scope of the
enclosing class without having its access specifier set, which results
in an assertion failure in SemaAccess.cpp later.
This commit fixes the crash by adding the parsed struct to the enclosing
file scope and marking structs as invalid if they are defined in
template parameter lists.
rdar://problem/31783961
rdar://problem/19570630
Differential Revision: https://reviews.llvm.org/D33606
llvm-svn: 306317
Add warn_drv_object_size_disabled_O0 to the invalid command line
argument group. This should fix some bot failures:
lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/13241/steps/test/logs/stdio
llvm-svn: 306183
This check currently isn't able to diagnose any issues at -O0, not is it
likely to [1]. Disabling the check at -O0 leads to substantial compile
time and binary size savings.
[1] [cfe-dev] Disabling ubsan's object size check at -O0
Differential Revision: https://reviews.llvm.org/D34563
llvm-svn: 306181
(possible implicit) noexcept specifier
Throwing in the destructor is not good (C++11 change try to not allow see below).
But in reality, those codes are exist.
C++11 [class.dtor]p3:
A declaration of a destructor that does not have an exception-specification is
implicitly considered to have the same exception specification as an implicit
declaration.
With this change, the application worked before may now run into runtime
termination. My goal here is to emit a warning to provide only possible info to
where the code may need to be changed.
First there is no way, in compile time to identify the “throw” really throw out
of the function. Things like the call which throw out… To keep this simple,
when “throw” is seen, checking its enclosing function(only destructor and
dealloc functions) with noexcept(true) specifier emit warning.
Here is implementation detail:
A new member function CheckCXXThrowInNonThrowingFunc is added for class Sema
in Sema.h. It is used in the call to both BuildCXXThrow and
TransformCXXThrowExpr.
The function basic check if the enclosing function with non-throwing noexcept
specifer, if so emit warning for it.
The example of warning message like:
k1.cpp:18:3: warning: ''~dependent_warn'' has a (possible implicit) non-throwing
noexcept specifier. Throwing exception may cause termination.
[-Wthrow-in-dtor]
throw 1;
^
k1.cpp:43:30: note: in instantiation of member function
'dependent_warn<noexcept_fun>::~dependent_warn' requested here
dependent_warn<noexcept_fun> f; // cause warning
Differential Revision: https://reviews.llvm.org/D33333
llvm-svn: 306149
Summary:
Add value completion support for options which are defined in
CC1Options.td, because we only handled options in Options.td.
Reviewers: ruiu, v.g.vassilev, teemperor
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D34558
llvm-svn: 306127
Restore the `-gz` option to the driver with some minor tweaks to handle
the additional case for `-Wa,--compress-debug-sections`.
This intends to make the compression of the debug information
controllable from the driver. The following is the behaviour:
-gz enable compression (ambiguous for format, will default to zlib-gnu)
-gz=none disable compression
-gz=zlib-gnu enable compression (deprecated GNU style zlib compression)
-gz=zlib enable compression (zlib based compression)
Although -Wa,-compress-debug-sections works, it should be discouraged
when using the driver to invoke the assembler. However, we permit the
assembler to accept the GNU as style argument --compress-debug-sections
to maintain compatibility.
Note, -gz/-gz= does *NOT* imply -g. That is, you need to additionally
specific -g for debug information to be generated.
llvm-svn: 306115
Summary: Style documentation is generated automatically by `docs/tools/dump_format_style.py`. This hasn't been ran for a while.
Reviewers: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D34457
llvm-svn: 306089
declarations that are owned but unconditionally visible.
This allows us to set declarations as visible even if they have a local owning
module, without losing information. In turn, that means that our Objective-C
support can keep on incorrectly assuming the "hidden" bit on the declaration is
the whole story with regard to name visibility. This will also be useful once
we support the C++ Modules TS export semantics.
Objective-C name visibility is still incorrect in any case where the "hidden"
bit is not the complete story: for instance, in Objective-C++ the set of
visible categories will be wrong during template instantiation, and with local
submodule visibility enabled it will be wrong when building modules. Fixing that
will require a major overhaul of how visibility is handled for Objective-C (and
particularly for categories).
llvm-svn: 306075
The new compiler warning -Wunguarded-availability-new is a subset of
-Wunguarded-availability. It is on by default. It only warns about uses of APIs
that have been introduced in macOS >= 10.13, iOS >= 11, watchOS >= 4 and
tvOS >= 11. We decided to use this kind of solution as we didn't want to turn
on -Wunguarded-availability by default, because we didn't want our users to get
warnings about uses of old APIs in their existing projects.
rdar://31054725
Differential Revision: https://reviews.llvm.org/D34264
llvm-svn: 306033
Summary:
This is the same as Inline, except it does not imply all empty
functions are merged: with this style, empty functions are merged only
if they also match the 'inline' criteria (i.e. defined in a class).
This is helpful to avoid inlining functions in implementations files.
Reviewers: djasper, krasimir
Reviewed By: djasper
Subscribers: klimek, rengolin, cfe-commits
Differential Revision: https://reviews.llvm.org/D34399
llvm-svn: 305912
Nico Weber