| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
After post-commit review and community discussion, this seems like a
reasonable direction to continue, making ownership semantics explicit in
the source using the type system.
llvm-svn: 215323
|
| |
|
|
| |
llvm-svn: 215322
|
| |
|
|
| |
llvm-svn: 215321
|
| |
|
|
| |
llvm-svn: 215320
|
| |
|
|
| |
llvm-svn: 215319
|
| |
|
|
| |
llvm-svn: 215318
|
| |
|
|
| |
llvm-svn: 215317
|
| |
|
|
| |
llvm-svn: 215316
|
| |
|
|
|
|
|
|
| |
thunks are needed
Reviewed at http://reviews.llvm.org/D4822
llvm-svn: 215312
|
| |
|
|
|
|
|
|
|
| |
one, perform the import if the types match even if the imported declaration is
hidden. Otherwise, NamedDecl::declarationReplaces will drop one of the name
lookup entries, making the typedef effectively inaccessible from one of the
modules that declared it.
llvm-svn: 215306
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While the test was already requiring shell-preserves-root (such as the
internal shell), it wasn't aware that the MSYS 1.0 env command knows how
to expand root by itself!
From cmd.exe try:
env SDKROOT=/ cmd //c echo %SDKROOT%
And get:
C:/MINGW/MSYS/1.0
To be certain we have a good 'env' program the test now requires a shell.
llvm-svn: 215298
|
| |
|
|
| |
llvm-svn: 215297
|
| |
|
|
|
|
| |
ScopedLineState
llvm-svn: 215294
|
| |
|
|
|
|
| |
From Matt Thomas.
llvm-svn: 215292
|
| |
|
|
| |
llvm-svn: 215291
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Clang :: Frontend/iframework.c
Clang :: Frontend/system-header-prefix.c
Clang :: Index/annotate-comments-objc.m
Clang :: Index/annotate-module.m
Clang :: Index/index-module.m
Clang :: Index/index-pch-with-module.m
Clang :: PCH/case-insensitive-include.c
Suprisingly the normalize_separators() was no-op when LLVM_ON_WIN32.
Its replacement native() does change path separators into \ as expected,
breaking these tests.
I had fixed the tests by #ifndef LLVM_ON_WIN32 on the native call,
to match the previous behaviour.
If this logic is not used on Windows host, it might be completely
deleted as there should not be windows path seperators on Linux hosts.
I can't test on Linux but if someone can run tests on Linux after
commenting out the line
llvm::sys::path::native(NormalizedPath);
and the tests pass, the whole if (LangOpts.MSVCCompat) could be deleted.
llvm-svn: 215290
|
| |
|
|
|
|
|
|
| |
return adjusting thunks
Reviewed at http://reviews.llvm.org/D4829
llvm-svn: 215285
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I reverted one of the added tests from r215261 in r215274, since it
was failing on quite a few bots. It looks like this wasn't sufficient,
as we're still getting failures on windows, like the following:
http://bb.pgr.jp/builders/ninja-x64-msvc-RA-centos6/builds/5378
I'm reverting this entire commit so the bots aren't blocked on these
failures.
This reverts commit r215261.
llvm-svn: 215278
|
| |
|
|
|
|
|
| |
The (new) CoverageMapping/macroparams.c test is failing on a number of
buildbots. Reverting it until Alex can investigate and fix the test.
llvm-svn: 215274
|
| |
|
|
|
|
|
| |
imported it from a module when performing finalization before writing out
an AST file.
llvm-svn: 215272
|
| |
|
|
|
|
|
|
|
| |
class Module. It's almost always going to be the same as
getContainingModule() for top-level modules, so just add a map to cover
the remaining cases. This lets us do less bookkeeping to keep the
ModuleMap fields up to date.
llvm-svn: 215268
|
| |
|
|
|
|
|
|
| |
This function might be a bit easier if it were split in two with a lot
of early returns - and that setOptional bit in the outer function, but
anyway.
llvm-svn: 215263
|
| |
|
|
|
|
|
|
|
|
| |
This patch adds the tests for the coverage mapping generation.
Most of the tests check the mapping regions produced by
the generator, and one checks the llvm IR.
Differential Revision: http://reviews.llvm.org/D4793
llvm-svn: 215261
|
| |
|
|
|
|
| |
Patch by Jim Grosbach.
llvm-svn: 215260
|
| |
|
|
|
|
|
|
|
| |
These macros are used as markers for Interface Builder and need to be defined
to empty strings since they have no impact on the code.
Patch by Ted Kremenek.
llvm-svn: 215259
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D4799
llvm-svn: 215258
|
| |
|
|
|
|
|
|
|
|
|
|
| |
indirection.
Summary: I was going to fix the use of raw pointer ownership in "takeGraph" when I realized that function was unused and the whole ExplodedGraph could just be owned by value without the std::unique_ptr indirection at all.
Reviewers: jordan_rose
Differential Revision: http://reviews.llvm.org/D4833
llvm-svn: 215257
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This flag can be used to force linking of CXX-specific parts
of sanitizer runtimes into the final executable. It gives more precise
control than --driver-mode=g++ and comes handy when user links several
object files with sanitized C++ code into an executable, but wants
to provide libstdc++ himself, instead of relying on Clang dirver's
behavior.
Test Plan: clang regression test suite
Reviewers: chandlerc, rsmith
Reviewed By: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D4824
llvm-svn: 215252
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
macro arguments.
Previously, these warnings skipped any code in a macro expansion. Preform an
additional check and warn when the expression and context locations are both
in the macro argument.
The most obvious case not caught is passing a pointer directly to a macro,
i.e 'assert(&array)' but 'assert(&array && "valid array")' is caught. This is
because macro arguments are not typed and the conversion happens inside the
macro.
llvm-svn: 215251
|
| |
|
|
|
|
|
| |
use mis-cased property name (which is currently accepted silently
due to the way property setters are named). rdar://17911746
llvm-svn: 215250
|
| |
|
|
| |
llvm-svn: 215246
|
| |
|
|
|
|
|
|
| |
The previous encoding only allowed a single digit for the minor version
number. This changes it to use 2 digits for both the minor version and the
revision number.
llvm-svn: 215245
|
| |
|
|
|
|
|
| |
llvm::sys::path::native has a superset of the functionality and this was the
only use of llvm::sys::fs::normalize_separators.
llvm-svn: 215242
|
| |
|
|
|
|
|
|
| |
It wasn't actually a bug that -mabicalls/-mno-abicalls wasn't being passed to
GAS. The only reason we pass it to the integrated assembler is because it shares
the same framework with CodeGen.
llvm-svn: 215236
|
| |
|
|
|
|
| |
rdar://17554063
llvm-svn: 215235
|
| |
|
|
|
|
|
| |
for building Objective-C array literals in ARC
mode. rdar://17554063
llvm-svn: 215232
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
the --use-cc option.
Instead, we will search in the PATH
For example:
scan-build --use-cc=arm-none-eabi-gcc -o out make -e
Initially reported as a Debian Bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=748777
llvm-svn: 215229
|
| |
|
|
|
|
|
|
|
|
|
|
| |
the debug info argument numbering.
Due to the possible presence of return-by-out parameters, using the LLVM
argument number count when numbering debug info arguments can end up
off-by-one. This could produce two arguments with the same number, which
would in turn cause LLVM to emit only one of those arguments (whichever
it found last) or assert (r215157).
llvm-svn: 215227
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
std::unique_ptr
Diving into the memory leaks fixed by r213851 there was one case of a
memory leak of a CompilationDatabase due to not properly taking
ownership of the result of "CompilationDatabase::autoDetectFromSource".
Given that both implementations and callers have been using unique_ptr
to own CompilationDatabase objects - make this explicit in the API to
reduce the risk of further leaks.
llvm-svn: 215215
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
possible for -mno-abicalls to take effect.
Also added the testcase that should have been in r215194.
This behaviour has surprised me a few times now. The problem is that the
generated MipsSubtarget::ParseSubtargetFeatures() contains code like this:
if ((Bits & Mips::FeatureABICalls) != 0) IsABICalls = true;
so '-abicalls' means 'leave it at the default' and '+abicalls' means 'set it to
true'. In this case, (and the similar -modd-spreg case) I'd like the code to be
IsABICalls = (Bits & Mips::FeatureABICalls) != 0;
or possibly:
if ((Bits & Mips::FeatureABICalls) != 0)
IsABICalls = true;
else
IsABICalls = false;
and preferably arrange for 'Bits & Mips::FeatureABICalls' to be true by default
(on some triples).
llvm-svn: 215211
|
| |
|
|
|
|
|
|
| |
Similar to r209767, which exposed other CUDA-related attributes.
Patch by Rob Springer.
llvm-svn: 215208
|
| |
|
|
|
|
|
| |
Based on a patch by Matheus Almeida. I've added testcases and fixed a bug where
the options weren't passed on to GAS.
llvm-svn: 215204
|
| |
|
|
| |
llvm-svn: 215202
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
string abc =
SomeFunction(aaaaaaaaaaaaa, aaaaa,
[]() { SomeOtherFunctioooooooooooooooooooooooooon(); });
After:
string abc = SomeFunction(aaaaaaaaaaaaa, aaaaa, []() {
SomeOtherFunctioooooooooooooooooooooooooon();
});
llvm-svn: 215197
|
| |
|
|
| |
llvm-svn: 215193
|
| |
|
|
|
|
|
|
|
| |
As we only create temp dtor decision branches when a temp dtor needs to
be run (as opposed to for each logical branch in the original
expression), we must include the information about all previous logical
branches when we annotate the temp dtor decision branch.
llvm-svn: 215188
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Array declarators involving the static keyword take on two forms:
D[ static type-qualifier-listopt assignment-expression ]
D[ type-qualifier-list static assignment-expression ]
Raise a diagnostic if the assignment-expression is missing.
This fixes PR20584.
llvm-svn: 215187
|
| |
|
|
| |
llvm-svn: 215177
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, assigning an inheritance model to a derived class would
trigger further assiginments to the various bases of the class. This
was done to fix a bug where we couldn't handle an implicit
base-to-derived conversion for pointers-to-members when the conversion
was ambiguous at an earlier point.
However, this is not how the MS scheme works. Instead, assign
inheritance models to *just* the class which owns to declaration we
ended up referencing.
N.B. This result is surprising in many ways. It means that it is
possible for a base to have a "larger" inheritance model than it's
derived classes. It also means that bases in the conversion path do not
get assigned a model.
struct A { void f(); void f(int); };
struct B : A {};
struct C : B {};
void f() { void (C::*x)() = &A::f; }
We can only begin to assign an inheritance model *after* we've seen the
address-of but *before* we've done the implicit conversion the more
derived pointer-to-member type. After that point, both 'A' and 'C' will
have an inheritance model but 'B' will not. Surprising, right?
llvm-svn: 215174
|
| |
|
|
|
|
|
|
|
| |
MSVC doesn't decide what the inheritance model for a returned member
pointer *until* a call expression returns it.
This fixes PR20017.
llvm-svn: 215164
|