Fixes a crash printing diagnostics on the gcc testsuite, and also makes
diagnostic range printing print nicer results for token pastes.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169068 91177308-0d34-0410-b5e6-96231b3b80d8
state so that all of the various clones end up rendering their
diagnostics into the same serialized-diagnostics file. This is
important when we actually want failures during module build to be
reported back to the translation unit that tried to import the
not-yet-built or out-of-date module. <rdar://problem/12565727>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169057 91177308-0d34-0410-b5e6-96231b3b80d8
the output size is greater than the register size. No truncation occurs with
those. Reword warning to make it clearer what's the problem is.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169054 91177308-0d34-0410-b5e6-96231b3b80d8
module, provide a module import stack similar to what we would get for
an include stack, e.g.,
In module 'DependsOnModule' imported from build-fail-notes.m:4:
In module 'Module' imported from DependsOnModule.framework/Headers/DependsOnModule.h:1:
Inputs/Module.framework/Headers/Module.h:15:12: note: previous definition is here
@interface Module
<rdar://problem/12696425>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169042 91177308-0d34-0410-b5e6-96231b3b80d8
building module 'Foo' imported from..." notes (the same we we provide
"In file included from..." notes) in the diagnostic, so that we know
how this module got included in the first place. This is part of
<rdar://problem/12696425>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169021 91177308-0d34-0410-b5e6-96231b3b80d8
import of that module elsewhere, don't try to build the module again:
it won't work, and the experience is quite dreadful. We track this
information somewhat globally, shared among all of the related
CompilerInvocations used to build modules on-the-fly, so that a
particular Clang instance will only try to build a given module once.
Fixes <rdar://problem/12552849>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@168961 91177308-0d34-0410-b5e6-96231b3b80d8
1) init-order sanitizer: initialization-order checker.
Status: usable, but may produce false positives w/o proper blacklisting.
2) use-after-return sanitizer
Status: implemented, but heavily understed.
Should be optional, as it significanlty slows program down.
3) use-after-scope sanitizer
Status: in progress.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@168950 91177308-0d34-0410-b5e6-96231b3b80d8
Note: the ":" goes into the regex because FileCheck wrongly complains about
unbalanced brackets otherwise.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@168934 91177308-0d34-0410-b5e6-96231b3b80d8
Among other differences, GCC accepts
typedef int IA[];
typedef int A10[10];
static A10 *f(void);
static IA *f(void);
void g(void) {
(void)sizeof(*f());
}
but clang used to reject it with:
invalid application of 'sizeof' to an incomplete type 'IA' (aka 'int []')
The intention of c99's 6.2.7 seems to be that we should use the composite type
and accept as gcc does.
Doing the type merging required some extra fixes:
* Use the type from the function type in initializations, even if an parameter
is available.
* Fix the merging of the noreturn attribute in function types.
* Make CodeGen handle the fact that an parameter type can be different from
the corresponding type in the function type.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@168895 91177308-0d34-0410-b5e6-96231b3b80d8
performed, to determine whether that special member is deleted or constexpr.
That overload resolution process can in turn trigger the instantiation of a
template, which can do anything, including triggering the declaration of that
very same special member function. When this happens, do not try to recursively
declare the special member -- that's impossible. Instead, only try to realise
the truth. There is no special member.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@168847 91177308-0d34-0410-b5e6-96231b3b80d8
in deciding a copy/dispose field is needed in a byref structure
and when generating the copy/dispose helpers. In certain
cases, these fields were being added but no copy/dispose was
being generated. This was uncovered in ARC, but not in MRR.
// rdar://12759433
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@168825 91177308-0d34-0410-b5e6-96231b3b80d8
decayed to a pointer type. Patch by WenHan Gu, with a little tweaking and
additional testcases by me.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@168822 91177308-0d34-0410-b5e6-96231b3b80d8
the original parameter or return type.
Since we do not accurately represent the data fields of a union, we should not
directly load or store a union type.
As an exmple, if we have i8,i8, i32, i32 as one field type and i32,i32 as
another field type, the first field type will be chosen to represent the union.
If we load with the union's type, the 3rd byte and the 4th byte will be skipped.
rdar://12723368
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@168820 91177308-0d34-0410-b5e6-96231b3b80d8
determine which member function would be the callee from within the template
definition, don't pass that function as a "non-member function" to
CreateOverloadedBinOp. Instead, just rely on it to select the member function
for itself.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@168818 91177308-0d34-0410-b5e6-96231b3b80d8
string literal needs cleaning (because it contains line-splicing in the
encoding prefix or in the ud-suffix), do not clean the section between the
double-quotes -- that's the "raw" bit!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@168776 91177308-0d34-0410-b5e6-96231b3b80d8
constructor/assignment operator with a const-qualified parameter type. The
prior method for determining this incorrectly used overload resolution.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@168775 91177308-0d34-0410-b5e6-96231b3b80d8
a special member" diagnostic from warning to error, and fix the cases where it
produced diagnostics with incorrect wording.
We don't support this as an extension, and we ban it even in C++98 mode. This
breaks too much (for instance, the ABI-specified calling convention for a type
can change if it acquires a copy constructor through the addition of a default
argument).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@168769 91177308-0d34-0410-b5e6-96231b3b80d8
The stop-gap here is to just drop such objects when processing the InitListExpr.
We still need a better solution.
Fixes <rdar://problem/12755044>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@168757 91177308-0d34-0410-b5e6-96231b3b80d8
This was also covered by <rdar://problem/12753384>. The static analyzer
evaluates a CXXConstructExpr within an initializer expression and
RegionStore doesn't know how to handle the resulting CXXTempObjectRegion
that gets created. We need a better solution than just dropping the
value, but we need to better understand how to implement the right
semantics here.
Thanks to Jordan for his help diagnosing the behavior here.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@168741 91177308-0d34-0410-b5e6-96231b3b80d8
objc_loadWeak. This retains and autorelease the weakly-refereced
object. This hidden autorelease sometimes makes __weak variable alive even
after the weak reference is erased, because the object is still referenced
by an autorelease pool. This patch overcomes this behavior by loading a
weak object via call to objc_loadWeakRetained(), followng it by objc_release
at appropriate place, thereby removing the hidden autorelease. // rdar://10849570
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@168740 91177308-0d34-0410-b5e6-96231b3b80d8