Sylvestre Ledru [Tue, 29 Oct 2013 13:01:41 +0000 (13:01 +0000)]
Use LLVMLibsOptions intead of LDFLAGS when setting the libclang soname. This allows 'make LDFLAGS=foo' to be set correctly (and matches the way it is done with libllvm and liblldb)
Tim Northover [Tue, 29 Oct 2013 12:32:58 +0000 (12:32 +0000)]
ARM: fix AST for __builtin_arm_strex call
The AST was constructed so that this builtin returned the default BoolTy and
since I'd opted for custom SemaChecking, I should have set it properly at that
point.
This caused an assertion failure when the types didn't match up with what we
generated. This makes it return an IntTy, which is as good as anything.
Chandler Carruth [Tue, 29 Oct 2013 10:27:30 +0000 (10:27 +0000)]
Teach the driver to not try to use 'lib32' multilib spellings on ARM
which doesn't use that multilib. As a consequence, fix Clang's support
for cross compiling environments that were relying on this quirk to
ensure the correct library search path ordering.
This also re-instates the new test cases from Rafael's r193528 for
cross-compiling to ARM on Ubuntu 13.10 without any of the changes to the
existing test cases (they were no longer needed).
This solution was the result of a lot of IRC debugging and trying to
understand *exactly* what quirk was being relied upon. It took some time
for me to figure out that it was the use of 'lib32' is a multilib that
was throwing a wrench in the works.
In case you are thinking that its silly to use a multilib of 'lib' at
all, entertainingly, GCC does so as well (you can see it with the
.../lib/../lib/crt1.o pattern it uses), and the 2-phase sequence of
search paths (multilib followed by non-multilib) has observable (if
dubious) consequences. =/ Yuck.
Chandler Carruth [Tue, 29 Oct 2013 08:53:03 +0000 (08:53 +0000)]
Clean up the deeply misleading name of the "MultiLibSuffix". This is
actually a MIPS-only hack to shim in random ABI directory suffixes in
numerous places throughout the toolchain's path search. It shouldn't
appear to be anything more general or useful.
Alp Toker [Tue, 29 Oct 2013 08:32:41 +0000 (08:32 +0000)]
Use Rewriter::overwriteChangedFiles() directly
This replaces the custom code in RefactoringTool::saveRewrittenFiles() which
lacked atomic file saving and error diagnostics, resolving an old FIXME from
r157331.
Landing this time with the proper return code, plus a very unhelpful comment
cleared up.
Chandler Carruth [Tue, 29 Oct 2013 02:27:56 +0000 (02:27 +0000)]
Cleanup comments and braces. No functionality changed, just trying to
record what is *actually* going on here as the comments existing in the
code are confusing at best, and in places outright misleading.
Richard Smith [Mon, 28 Oct 2013 22:18:19 +0000 (22:18 +0000)]
Allow a new syntax in a module requires-declaration:
requires ! feature
The purpose of this is to allow (for instance) the module map for /usr/include
to exclude <tgmath.h> and <complex.h> when building in C++ (these headers are
instead provided by the C++ standard library in this case, and the glibc C
<tgmath.h> header would otherwise try to include <complex.h>, resulting in a
module cycle).
David Majnemer [Sat, 26 Oct 2013 05:02:13 +0000 (05:02 +0000)]
Sema: Correctly build pointer-to-member arguments from a template argument with an IndirectFieldDecl
We only considered FieldDecl and CXXMethodDecl as appropriate which
would cause us to believe the IndirectFieldDecl corresponded to an
argument of it's field type instead of a pointer-to-member type.
Jordan Rose [Fri, 25 Oct 2013 16:52:00 +0000 (16:52 +0000)]
Add -Wstring-plus-char, which warns when adding char literals to C strings.
Specifically, this warns when a character literal is added (using '+') to a
variable with type 'char *' (or any other pointer to character type). Like
-Wstring-plus-int, there is a fix-it to change "foo + 'a'" to "&foo['a']"
iff the character literal is on the right side of the string.
Richard Trieu [Fri, 25 Oct 2013 00:56:00 +0000 (00:56 +0000)]
Simplify and refactor the uninitialized field warning.
Change the uninitialized field warnings so that field initializers are checked
inside the constructor. Previously, in class initializers were checked
separately. Running one set of checks also simplifies the logic for preventing
duplicate warnings. Added new checks to warn when an uninitialized field is
used in base class initialization. Also fixed misspelling of uninitialized
and moved all code for this warning together.
Because of the #if-#else structure, the code is formatted and annotated
twice and becauce of the nested block, the annotated lines form a
hierarchical structure. This structure was not properly reset between
runs.
Chandler Carruth [Thu, 24 Oct 2013 09:21:37 +0000 (09:21 +0000)]
Teach Clang to accept and ignore -f[no-]implicit-templates.
This GCC flag is useful when you want to control whether implicit
template instantiation occurs at the commandline level. Clang doesn't
currently support such controls, but technically *always* implicitly
instantiating (what Clang does, and what every other compiler still in
use does by default) is valid behavior even under
-fno-implicit-templates, it just may be slow and very wasteful. If
people really want this, we can try to implement it, but I don't have an
actual use.
This should help fix the build of libstdc++ with Clang, its build system
uses this flag.
Chandler Carruth [Thu, 24 Oct 2013 09:17:35 +0000 (09:17 +0000)]
Teach Clang to recognize and ignore GCC's -fdiagnostics-show-location
flag. We should probably wire at least some variants of this up to our
actual diagnostics engine, but I'm leaving that for someone else. This
fixes the builds of packages which hard code something here, at least
including libstdc++ itself.
Manuel Klimek [Thu, 24 Oct 2013 07:51:24 +0000 (07:51 +0000)]
Use the same SourceManager for ModuleMaps and compilations.
This allows using virtual file mappings on the original SourceManager to
map in virtual module.map files. Without this patch, the ModuleMap
search will find a module.map file (as the FileEntry exists in the
FileManager), but will be unable to get the content from the
SourceManager (as ModuleMap previously created its own SourceManager).
Two problems needed to be fixed which this patch exposed:
1. Storing the inferred module map
When writing out a module, the ASTWriter stores the names of the files
in the main source manager; when loading the AST again, the ASTReader
errs out if such a file is found missing, unless it is overridden.
Previously CompilerInstance's compileModule method would store the
inferred module map to a temporary file; the problem with this approach
is that now that the module map is handled by the main source manager,
the ASTWriter stores the name of the temporary module map as source to
the compilation; later, when the module is loaded, the temporary file
has already been deleted, which leads to a compilation error. This patch
changes the inferred module map to instead inject a virtual file into
the source manager. This both saves some disk IO, and works with how the
ASTWriter/ASTReader handle overridden source files.
2. Changing test input in test/Modules/Inputs/*
Now that the module map file is handled by the main source manager, the
VerifyDiagnosticConsumer will not ignore diagnostics created while
parsing the module map file. The module test test/Modules/renamed.m uses
-I test/Modules/Inputs and triggers recursive loading of all module maps
in test/Modules/Inputs, some of which had conflicting names, thus
leading errors while parsing the module maps. Those diagnostics already
occur on trunk, but before this patch they would not break the test, as
they were ignored by the VerifyDiagnosticConsumer. This patch thus
changes the module maps that have been recently introduced which broke
the invariant of compatible modules maps in test/Modules/Inputs.
Richard Smith [Thu, 24 Oct 2013 01:07:54 +0000 (01:07 +0000)]
PR17666: Instead of allowing an initial identifier argument in any attribute
which we don't think can't have one, only allow it in the tiny number of
attributes which opts into this weird parse rule.
I've manually checked that the handlers for all these attributes can in fact
cope with an identifier as the argument. This is still somewhat terrible; we
should move more fully towards picking the parsing rules based on the
attribute, and make the Parse -> Sema interface more type-safe.
Faisal Vali [Thu, 24 Oct 2013 01:05:22 +0000 (01:05 +0000)]
Fix an instantiation bug with nested generic lambdas and conversion to fptrs.
This patch fixes the typelocs of the conversion-operator and the conversion-operator-name and adds the parameters of the call operator to the FunctionProtoTypeLoc of the respective entities. Thus, when the template declarations (conversion operators) undergo deduction and instantiation/transformation/substitution - they add themselves to the local instantiation scope if needed.
This patch supports the following:
auto L = [](auto b) {
return [](auto a) ->decltype(a) { return a; };
};
int (*fp)(int) = L(8);
Richard LGTM'd this patch: http://llvm-reviews.chandlerc.com/D1831
Warren Hunt [Wed, 23 Oct 2013 23:53:07 +0000 (23:53 +0000)]
Implements 64 bit microsoft record layout and adds lit tests to cover
it. Also removes all of the microsoft C++ ABI related code from the
itanium layout builder.
David Majnemer [Wed, 23 Oct 2013 21:31:20 +0000 (21:31 +0000)]
Parse: Disable delayed template parsing for constexpr functions
Commit r191484 treated constexpr function templates as normal function
templates with respect to delaying their parsing. However, this is
unnecessarily restrictive because there is no compatibility concern with
constexpr, MSVC doesn't support it.
Instead, simply disable delayed template parsing for constexpr function
templates. This largely reverts the changes made in r191484 but keeps
it's unit test.
David Majnemer [Wed, 23 Oct 2013 20:52:43 +0000 (20:52 +0000)]
AST: Mangle fields in anonymous structs/unions
The Itanium mangler couldn't cope with mangling an IndirectFieldDecl.
Instead, mangle the field the IndirectFieldDecl refers to.
Further, give IndirectFieldDecl no linkage just like FieldDecl.
N.B. Decl.cpp:getLVForNamespaceScopeDecl tried to calculate linkage for
data members of anonymous structs/unions. However, this seems
impossible so turn it into an assertion.
Jordan Rose [Wed, 23 Oct 2013 20:08:55 +0000 (20:08 +0000)]
[analyzer] Generate a LazyCompoundVal when loading from a union-typed region.
This ensures that variables accessible through a union are invalidated when
the union value is passed to a function. We still don't fully handle union
values, but this should at least quiet some false positives.
Faisal Vali [Wed, 23 Oct 2013 16:10:50 +0000 (16:10 +0000)]
Refactor out the circular reference to LambdaExpr in CXXRecordDecl.
A prior commit of this patch was reverted because it was within the blamelist's purview of a failing test. The failure of that test has been addressed here: http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20131021/091546.html. Therefore I am recommitting this patch (all tests pass on windows, except for the usual modules & index suspects that never pass on my box).
Some background: Both Doug and Richard had asked me in Chicago to remove the circular reference in CXXRecordDecl to LambdaExpr by factoring out and storing the needed information from LambdaExpr directly into CXXRecordDecl.
In addition, I have added an IsGenericLambda flag - this makes life a little easier when we implement capturing, and are Sema-analyzing the body of a lambda (and the calloperator hasn't been wired to the closure class yet). Any inner lambdas can have potential captures that could require walking up the scope chain and checking if any generic lambdas are capture-ready. This 'bit' makes some of that checking easier.
No change in functionality.
This patch was approved by Doug with minor modifications (comments were cleaned up, and all data members were converted from bool/enum to unsigned, as requested):
http://llvm-reviews.chandlerc.com/D1856
Daniel Sanders [Wed, 23 Oct 2013 10:12:44 +0000 (10:12 +0000)]
[mips][msa] Add intrinsics that map to pseudo-instructions.
Unlike the previously added intrinsics, these do not map to a single instruction
on MIPS32. They are provided for regularity (to round out the .[bhw] variants
of the same operation) and compatibility with GCC.
Faisal Vali [Wed, 23 Oct 2013 06:44:28 +0000 (06:44 +0000)]
And Again: Teach TreeTransform how to transform nested generic lambdas.
A previous attempt http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20130930/090049.html resulted in PR 17476, and was reverted,
The original TransformLambdaExpr (pre generic-lambdas) transformed the TypeSourceInfo of the Call operator in its own instantiation scope via TransformType. This resulted in the parameters of the call operator being mapped to their transformed counterparts in an instantiation scope that would get popped off.
Then a call to TransformFunctionParameters would add the parameters and their transformed mappings (but newly created ones!) to the current instantiation scope. This would result in a disconnect between the new call operator's TSI parameters and those used to construct the call operator declaration. This was ok in the non-generic lambda world - but would cause issues with nested transformations (when non-generic and generics were interleaved) in the generic lambda world - that I somewhat kludged around initially - but this resulted in PR17476.
The new approach seems cleaner. We only do the transformation of the TypeSourceInfo - but we make sure to do it in the current instantiation scope so we don't lose the untransformed to transformed mappings of the ParmVarDecls when they get created.
Another attempt caused a test to fail (http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20131021/091533.html) and also had to be reverted - my apologies - in my haste, i did not run all the tests - argh!
Now all the tests seem to pass - but a Fixme has been added - since I suspect Richard will find the fix a little inelegant ;) I shall try and work on a more elegant fix once I have had a chance to discuss with Richard or Doug at a later date.
Hopefully the third time;s a charm *fingers crossed*
This does not yet include capturing.
Please see test file for examples.
This patch was LGTM'd by Doug:
http://llvm-reviews.chandlerc.com/D1784
Faisal Vali [Wed, 23 Oct 2013 02:59:27 +0000 (02:59 +0000)]
Remove the circular reference to LambdaExpr in CXXRecordDecl.
Both Doug and Richard had asked me to remove the circular reference in CXXRecordDecl to LambdaExpr by factoring out and storing the needed information from LambdaExpr directly into CXXRecordDecl.
No change in functionality.
In addition, I have added an IsGenericLambda flag - this makes life a little easier when we implement capturing, and are Sema-analyzing the body of a lambda (and the calloperator hasn't been wired to the closure class yet). Any inner lambdas can have potential captures that could require walking up the scope chain and checking if any generic lambdas are capture-ready. This 'bit' makes some of that checking easier.
This patch was approved by Doug with minor modifications (comments were cleaned up, and all data members were converted from bool/enum to unsigned, as requested):
http://llvm-reviews.chandlerc.com/D1856
Richard Smith [Wed, 23 Oct 2013 02:17:46 +0000 (02:17 +0000)]
Make UsingShadowDecls redeclarable. This fixes some visibility problems with
modules.
With this fixed, I no longer see any test regressions in the libc++ test suite
when enabling a single-module module.map for libc++ (other than issues with my
system headers).
Faisal Vali [Wed, 23 Oct 2013 00:51:58 +0000 (00:51 +0000)]
Again: Teach TreeTransform and family how to transform generic
lambdas nested within templates and themselves.
A previous attempt http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20130930/090049.html resulted in PR 17476, and was reverted,
The original TransformLambdaExpr (pre generic-lambdas) transformed the TypeSourceInfo of the Call operator in its own instantiation scope via TransformType. This resulted in the parameters of the call operator being mapped to their transformed counterparts in an instantiation scope that would get popped off.
Then a call to TransformFunctionParameters would add the parameters and their transformed mappings (but newly created ones!) to the current instantiation scope. This would result in a disconnect between the new call operator's TSI parameters and those used to construct the call operator declaration. This was ok in the non-generic lambda world - but would cause issues with nested transformations (when non-generic and generics were interleaved) in the generic lambda world - that I somewhat kludged around initially - but this resulted in PR17476.
The new approach seems cleaner. We only do the transformation of the TypeSourceInfo - but we make sure to do it in the current instantiation scope so we don't lose the untransformed to transformed mappings of the ParmVarDecls when they get created.
This does not yet include capturing.
Please see test file for examples.
This patch was LGTM'd by Doug:
http://llvm-reviews.chandlerc.com/D1784