DiagIDs are a cached resource generally only constructed from compile-time
constant or stable format strings.
Escaping arbitrary messages and constructing DiagIDs from them didn't make
sense.
llvm-svn: 197856
This new warning detects when a function will recursively call itself on every
code path though that function. This catches simple recursive cases such as:
void foo() {
foo();
}
As well as more complex functions like:
void bar() {
if (test()) {
bar();
return;
} else {
bar();
}
return;
}
This warning uses the CFG. As with other CFG-based warnings, this is off
by default. Due to false positives, this warning is also disabled for
templated functions.
llvm-svn: 197853
Without this patch, record decls with invalid out-of-line method delcs would
sometimes be marked invalid, but not always. With this patch, they are
consistently never marked invalid.
(The code to do this was added in
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20100809/033154.html
, but the test from that revision is still passing.)
As far as I can tell, this was the only place where a class was marked invalid
after its definition was complete.
llvm-svn: 197848
Now CodeGenVTables has only one VTableContext object, which is either
Itanium or Microsoft.
Fixes a FIXME with no functionality change intended.
Ideally we could avoid the downcasts by pushing the things that
reference the Itanium vtable context into ItaniumCXXABI.cpp, but we're
not there yet.
llvm-svn: 197845
These members will still be lazily added to the relevant DWARF DIEs in
LLVM but when enumerating the members they will not appear. This allows
DWARF type units to be more consistent - the type unit will never
contain these special members (so all instances of the type should have
the same DIEs without some having some special members and others having
others) and the special members will be added to the skeletal
declaration that appears in the relevant compile_unit.
llvm-svn: 197844
This matches llc's behavior.
Before this patch clang would create a TargetInfo base on -triple but a llvm
CodeGen based on the triple in the module.
llvm-svn: 197837
This was part of the cause for PR17655. We were generating thunks when
we shouldn't have. I suspect that if we tweak the test case for PR17655
to actually require thunks, we can reproduce the same crash.
llvm-svn: 197836
If a header file belonging to a certain module is not found on the
filesystem, that header gets marked as unavailable. Now, the layering
warning (-fmodules-decluse) should still warn about headers of this
module being wrongfully included. Currently, headers belonging to those
modules are just treated as not belonging to modules at all which means
they can be included freely from everywhere.
To implement this (somewhat) cleanly, I have moved most of the layering
checks into the ModuleMap. This will also help with showing FixIts
later.
llvm-svn: 197805
This caused some crazy crashes involving std::unordered_map being
deserialized from a PCH file and then template instantiation requiring
an explicit instantiation location; unfortunately I don't really know
how to come up with a minimal test case.
llvm-svn: 197764
files to tell if they were changed since the last time we have computed the
preamble
We used to check only the buffer size, so if the new remapped buffer has the
same size as the previous one, we would think that the buffer did not change,
and we did not rebuild the preambule, which sometimes caused us to crash.
llvm-svn: 197755
We have assertions for this, but a few edge cases had snuck through where
we were still unconditionally using 'int'.
<rdar://problem/15703011>
llvm-svn: 197733
A comment following the "{" of a braced list seems to almost always
refer to the first element of the list and thus should be aligned
to it.
Before (with Cpp11 braced list style):
SomeFunction({ // Comment 1
"first entry",
// Comment 2
"second entry"});
After:
SomeFunction({// Comment 1
"first entry",
// Comment 2
"second entry"});
llvm-svn: 197725
Unexpectedly, it seems that people commonly know what they were doing
when writing a comment.
Also, being more conservative about comment breaking has the advantage
of giving more flexibility. If a linebreak within the comment can
improve formatting, the author can add it (after which clang-format
won't undo it). There is no way to override clang-format's behavior if
it breaks a comment.
llvm-svn: 197698
We started by trying to deserialize decltype(func-param) in a trailing return
type, which causes the function parameter decl to be deserialized, which pulls
in the function decl, which pulls the function type, which pulls the same
decltype() in the return type, and then we crashed.
llvm-svn: 197644
The alignment impact of the virtual bases apperas to be applied in
order, rather than up front. This patch adds the new behavior and
provides a test case.
llvm-svn: 197639
Fixes <rdar://problem/15584219> and <rdar://problem/12241361>.
This change looks large, but all it does is reuse and consolidate
the delayed diagnostic logic for deprecation warnings with unavailability
warnings. By doing so, it showed various inconsistencies between the
diagnostics, which were close, but not consistent. It also revealed
some missing "note:"'s in the deprecated diagnostics that were showing
up in the unavailable diagnostics, etc.
This change also changes the wording of the core deprecation diagnostics.
Instead of saying "function has been explicitly marked deprecated"
we now saw "'X' has been been explicitly marked deprecated". It
turns out providing a bit more context is useful, and often we
got the actual term wrong or it was not very precise
(e.g., "function" instead of "destructor"). By just saying the name
of the thing that is deprecated/deleted/unavailable we define
this issue away. This diagnostic can likely be further wordsmithed
to be shorter.
llvm-svn: 197627
The problem here is more serious than the fix implies. Adding a field
to a class updates the triviality bits for the class (among other
things). Failing to require a complete type before adding the field
meant that these updates don't happen in the well-formed case where
the capture is an uninstantiated class template specialization,
leading the lambda itself to be treated as having a trivial copy
constructor when it shouldn't. Fixes <rdar://problem/15560464>.
llvm-svn: 197623
Aaron Ballman