The former name doesn't make sense, we are using this parameter for both .a and .dylib libraries.
No functional change.
http://reviews.llvm.org/D6040
llvm-svn: 220939
Instead of manually maintaining a flag indicating whether we're about to print
out the last child of the parent node (to determine whether we print "`" or
"|"), capture a callable to print that child and defer printing it until we
either see a next child or finish the parent.
No functionality change intended.
llvm-svn: 220930
SanitizerOptions is not even a POD now, so having global variable of
this type, is not nice. Instead, provide a regular constructor and clear()
method, and let each CodeGenFunction has its own copy of SanitizerOptions
it uses.
llvm-svn: 220920
This moves classes for storing and applying replacements to separate
files. These classes specifically are used by clang-format which doesn't
have any other dependencies on clangAST. Thereby, the size of
clang-format's binary can be cut roughly in half and its build time sped
up.
llvm-svn: 220867
Previously a regex-literal containing "/*" would through clang-format
off, e.g.:
var regex = /\/*$/;
Would lead to none of the following code to be formatted.
llvm-svn: 220860
The Windows NT SDK uses __readfsdword and declares it as a compiler provided
builtin (#pragma intrinsic(__readfsword). Because intrin.h is not referenced
by winnt.h, it is not possible to provide an out-of-line definition for the
intrinsic. Provide a proper compiler builtin definition.
llvm-svn: 220859
Following the NVVM IR specifications, arguments of aggregate type should be
passed on the stack without splitting (byval).
http://reviews.llvm.org/D6020
Patch by Jacques Pienaar.
llvm-svn: 220854
As discussed in bug 21398, PowerPC ABI code needs to consider C++ base
classes when classifying a class as homogeneous aggregate (or not) for
ABI purposes.
llvm-svn: 220852
An updated implemnentation of VLA types capturing based on previously committed solution for Lambdas.
This version captures the whole VLA type instead of particular variables which are part of VLA size expression and allows to use previusly calculated size of VLA type in captured regions. Required for OpenMP.
Differential Revision: http://reviews.llvm.org/D5099
llvm-svn: 220850
DeclarationNameInfo::getInfo() returns reference, but DeclRefExpr::getNameInfo() returns temporary DeclarationNameInfo().
It triggered a local crash for me.
Failing Tests (1):
Clang :: SemaTemplate/instantiate-overload-candidates.cpp
Assertion failed!
Program: bin\clang.EXE
File: clang/lib/Basic/SourceManager.cpp, Line 822
Expression: 0 && "Invalid SLocOffset or bad function choice"
llvm-svn: 220841
Before:
ReturnType MACRO
FunctionName() {}
After:
ReturnType MACRO
FunctionName() {}
This fixes llvm.org/PR21404.
I wonder what the motivation for that if-condition was. But as no test
breaks, ...
llvm-svn: 220801
Apparently, people are very much divided on what the "correct"
indentation is. So, best to give them a choice.
The new flag is called ObjCBlockIndentWidth and the default is now set
to the same value as IndentWidth for the pre-defined styles.
llvm-svn: 220784
explicitly using the resulting .pcm file. Unlike for an implicit module build,
we don't need nor want to require these flags to match between the module
and its users.
llvm-svn: 220780
Summary:
We should avoid a tail padding not only if the last field
has zero size but also if the last field is a struct with a flexible array.
If/when http://reviews.llvm.org/D5478 is committed,
this will also handle the case of structs with zero-sized arrays.
Reviewers: majnemer, rsmith
Reviewed By: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D5924
llvm-svn: 220708
This includes adding the new TypoExpr-based lazy typo correction to
LookupMemberExprInRecord as an alternative to the existing eager typo
correction.
llvm-svn: 220698
matches of the typo.
Also be more proactive about checking a correction's visibility so that
a correction requiring a module import can be distinguished from the
original typo even if it looks identical. Otherwise the correction will
be excluded and the diagnostic about needing the module import won't be
emitted.
Note that no change was made to checkCorrectionVisibility other than
moving where it is at in SemaLookup.cpp.
llvm-svn: 220696
Part of the infrastructure is a map from a TypoExpr to the Sema-specific
state needed to correct it, along with helpers to ease dealing with the
state.
The the typo count is propagated up the stack of
ExpressionEvaluationContextRecords when one is popped off of to
avoid accidentally dropping TypoExprs on the floor. For example,
the attempted correction of g() in test/CXX/class/class.mem/p5-0x.cpp
happens with an ExpressionEvaluationContextRecord that is popped off
the stack prior to ActOnFinishFullExpr being called and the tree
transform for TypoExprs being run.
llvm-svn: 220695
Two additional methods are provided: one to return the current
correction (the last correction returned by getNextCorrection), and one
to "reset" the state so that getNextCorrection will return the previous
corrections before returning any new corrections.
Also ensure that all TypoCorrections have valid source ranges.
llvm-svn: 220694
This makes it available outside of SemaLookup.cpp, as
needed for the forthcoming TypoExpr AST node which will
keep a TypoCorrectionConsumer that provides the possible
typo corrections for that TypoExpr.
llvm-svn: 220691
Before:
void
SomeFunction(int parameter);
After:
void SomeFunction(
int parameter);
(Unless AlwaysBreakAfterDefinitionReturnType after type is set).
llvm-svn: 220686
Summary:
Speed up clang-tidy when profiling in on.
It makes profiling runs twice as fast by reusing the time samples between the
different actions.
It also joins together the sampling of different matchers of the same check.
Reviewers: alexfh
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D5972
llvm-svn: 220682
Rather than asserting that the target is unsupported, make a guess at what the
tree for a port would look like and use that for the search path.
Addresses review comments from Ried Kleckner for SVN r220547.
llvm-svn: 220624
We would crash because we used operator[] to access past the end of a
SmallString. This occured because our token had length zero.
Instead, form the pointer using .data() and arithmetic. This is safe
because this forms a one-past-the-end pointer and it is only used to
compare with another one-past-the-end pointer.
This fixes PR21379.
llvm-svn: 220614
The MS linker cannot do anything interesting with these, it doesn't make
sense to emit them.
This fixes PR21373.
Differential Revision: http://reviews.llvm.org/D5986
llvm-svn: 220595
Avoid an assertion when materializing a lifetime type aggregate temporary. When
performing CodeGen for ObjC++, we could generate a lifetime-only aggregate
temporary by using an initializer list (which is effectively an array). We
would reach through the temporary expression, fishing out the inner expression.
If this expression was a lifetime expression, we would attempt to emit this as a
scalar. This would eventually result in an assertion as the emission would
eventually assert that the expression being emitted has a scalar evaluation
kind.
Add a case to handle the aggregate expressions. Use the EmitAggExpr to emit the
aggregate expression rather than the EmitScalarInit.
Addresses PR21347.
llvm-svn: 220590
Template template parameters weren't added to the list of substitutions.
This would make the substitution map contain inaccurate mappings,
leading to Clang violating the Itanium ABI and breaking compatibility
with GCC.
This fixes PR21351.
Differential Revision: http://reviews.llvm.org/D5959
llvm-svn: 220588
This fixes a corner-case where __uuidof as a template argument would
result in us trying to emit a GLValue as an RValue. This would lead to
a crash down the road.
llvm-svn: 220585
Wire it through everywhere we have support for fastcall, essentially.
This allows us to parse the MSVC "14" CTP headers, but we will
miscompile them because LLVM doesn't support __vectorcall yet.
Reviewed By: Aaron Ballman
Differential Revision: http://reviews.llvm.org/D5808
llvm-svn: 220573
Summary:
This allows us to easily identify them in the backend which in turn allows us
to handle them correctly for big-endian targets (where they must be shifted
into the upper bits of the register).
Depends on D5961
Reviewers: atanasyan
Reviewed By: atanasyan
Subscribers: cfe-commits, theraven
Differential Revision: http://reviews.llvm.org/D5962
llvm-svn: 220566
Summary:
Ensure all integral/enumeration types are appropriately annotated with
signext/zeroext. In particular, i32 now has these attributes when using the
N32/N64 ABI. This paves the way for accurately representing the way the
N32/N64 ABI's promotes integer arguments to i64.
Reviewers: atanasyan
Reviewed By: atanasyan
Subscribers: cfe-commits, theraven
Differential Revision: http://reviews.llvm.org/D5961
llvm-svn: 220563
This fixes a crash in the RecursiveASTVisitor on such code
__typeof__(struct F*) var[invalid];
The UnderlyingTInfo of a TypeOfTypeLoc was left uninitialized when
created from ASTContext::getTrivialTypeSourceInfo
This lead to a crash in RecursiveASTVisitor when trying to access it.
llvm-svn: 220562
'char' is unsigned on all ARM and Thumb architectures. Clang gets this
right for ARM, and for thumb when using and arm triple and the -mthumb
option, but gets it wrong for thumb triples. This fixes that.
llvm-svn: 220555
This is a very basic toolchain. It supports cross-compiling Windows (primarily
inspired by the WoA target). It is meant to use clang with the LLVM IAS and a
binutils ld-compatible interface for the linker (eventually to be lld). It does
not perform any "standard" GCC lookup, nor does it perform any special
adjustments given that it is expected to be used in an environment where the
user is using MSVCRT (and as such Visual Studio headers) and the Windows SDK.
The primary runtime library is expected to be compiler-rt and the C++
implementation to be libc++.
It also expects that a sysroot has been setup given the usual Unix semantics
(standard C headers in /usr/include, all the import libraries available in
/usr/lib). It also expects that an entry point stub is present in /usr/lib
(crtbegin.obj for executables, crtbeginS.obj for shared libraries).
The entry point stub is responsible for running any GNU constructors.
llvm-svn: 220546
Clang would previously assert on the following code when targeting MinGW:
struct __declspec(dllimport) S {
virtual ~S();
};
S::~S() {}
Because ~S is a key function and the class is dllimport, we would try to emit a
strong definition of the vtable, with dllimport - which is a conflict. We
should not emit strong vtable definitions for imported classes.
Differential Revision: http://reviews.llvm.org/D5944
llvm-svn: 220532
Currently, when --serialize-diagnostics is passed this only includes
the diagnostics from clang -cc1, and driver diagnostics are
dropped. This causes issues for tools that use the serialized
diagnostics, since stderr is lost and these diagnostics aren't seen at
all.
We handle this by merging the diagnostics from the CC1 process and the
driver diagnostics into a single file when the driver invokes CC1.
Fixes rdar://problem/10585062
llvm-svn: 220525
nonnull attribute when comparison is always
true/false. Patch by Steven Wu with few fixes and minor
refactoring and adding tests by me. rdar://18712242
llvm-svn: 220496
Since the order of the IDs in the AST file (e.g. DeclIDs, SelectorIDs)
is not stable, it is not safe to load an AST file that depends on
another AST file that has been rebuilt since the importer was built,
even if "nothing changed". We previously used size and modtime to check
this, but I've seen cases where a module rebuilt quickly enough to foil
this check and caused very hard to debug build errors.
To save cycles when we're loading the AST, we just generate a random
nonce value and check that it hasn't changed when we load an imported
module, rather than actually hash the whole file.
This is slightly complicated by the fact that we need to verify the
signature inside addModule, since we might otherwise consider that a
mdoule is "OutOfDate" when really it is the importer that is out of
date. I didn't see any regressions in module load time after this
change.
llvm-svn: 220493
The previous IR representation used the non-lexical decl context, which
placed the definitions in the same scope as the declarations (ie: within
the class) - this was hidden by the fact that LLVM currently doesn't
respect the context of global variable definitions at all, and always
puts them at the top level (as direct children of the compile_unit).
Having the correct lexical scope improves source fidelity and simplify
backend global variable emission (with changes coming shortly).
Doing something similar for non-member global variables would help
simplify/cleanup things further (see FIXME in the commit) and provide
similar source fidelity benefits to the final debug info.
llvm-svn: 220488
This was not a real header role, and was never exposed to clients of ModuleMap.
Remove the enumeration value for it and track it as marking the header as
'known' rather than creating an extra KnownHeader entry that *every single*
client ignores.
llvm-svn: 220460
This is a sad thing to do, but all the alternatives look ugly.
Looks like there are legitimate cases when users may want to link
with sanitizer runtimes *and* -nodefaultlibs (and ensure they provide
replacements for system libraries). For example, this happens in libc++
test suite.
"-nodefaultlibs" is told to link only the libraries explicitly provided
by the user, and providing "-fsanitize=address" is a clear indication of
intention to link with ASan runtime.
We can't easily introduce analogue of "-print-libgcc-name": linking with
sanitizers runtimes is not trivial: some runtimes are split into several
archive libraries, which are required to be wrapped in
-whole-archive/-no-whole-archive.
If "-fsanitize=whatever" and "-nodefaultlibs" are provided, system library
dependencies of sanitizer runtimes (-lc/-ldl/-lpthread/-lrt) will *not* be
linked, and user would have to link them in manually. Note that this can
cause problems, as failing to provide "-lrt" might lead to crashes in runtime
during ASan initialization. But looks like we should bite this bullet.
See r218541 review thread for the discussion.
llvm-svn: 220455
This allows a module to specify that it logically contains a file, but that
said file is non-modular and intended for textual inclusion. This allows
layering checks to work properly in the presence of such files.
llvm-svn: 220448
When a user has not configured a standard Visual Studio environment
by running vcvarsall, clang tries its best to find Visual Studio
include files and executables anyway. This patch makes clang also
try to find system and Windows SDK libraries for linking against,
as well.
Reviewed by: Hans Wennborg
Differential Revision: http://reviews.llvm.org/D5873
llvm-svn: 220425
This resubmits change r220226. That change broke the chromium
build bots because chromium it ships an hermetic MSVC toolchain
that it expects clang to fallback to by finding it on the path.
This patch fixes the issue by bumping up the prioritization of PATH
when looking for MSVC binaries.
Reviewed by: Hans Wennborg, Reid Kleckner
Differential Revision: http://reviews.llvm.org/D5892
llvm-svn: 220424
Summary:
Add support for profiling the matchers used.
This will be connected with clang-tidy to generate a report to determine
and debug slow checks.
Reviewers: alexfh
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D5911
llvm-svn: 220418
It's not clear how this would be tested - I imagine we should have an
ASTImporter test that RAVs the new AST and checks that all the elements
in it are from this ASTContext and not the foreign one... but I know
little about the ASTImporter and how/where that testing might be done.
(post-commit review feedback from Richard Smith on r219900)
llvm-svn: 220411
When SanitizerBlacklist decides if the SourceLocation is blacklisted,
we need to first turn it into a SpellingLoc before fetching the filename
and scanning "src:" entries. Otherwise we will fail to fecth the
correct filename for function definitions coming from macro expansion.
llvm-svn: 220403
Original message:
Add a second late template parser callback meant to cleanup any
resources allocated by late template parsing. Call it from the
Sema::ActOnEndOfTranslationUnit method after all pending template
instantiations have been completed. Teach Parser::ParseTopLevelDecl to
install the cleanup callback when incremental processing is enabled so
that Parser::TemplateIds can be freed.
Patch by Brad King!
llvm-svn: 220400
This eliminates some i8* GEPs and makes the IR that clang emits a bit
more canonical. More work is needed for vftables, but that isn't a clear
win so I plan to send it for review.
llvm-svn: 220398
Summary:
When using a profile, we used to require the use -gmlt so that we could
get access to the line locations. This is used to match line numbers in
the input profile to the line numbers in the function's IR.
But this is actually not necessary. The driver can provide source
location tracking without the emission of debug information. In these
cases, the annotation 'llvm.dbg.cu' is missing from the IR, but the
actual line location annotations are still present.
This patch tells the driver to only emit source location tracking
when -fprofile-sample-use is present in the command line.
Reviewers: echristo, dblaikie
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D5888
llvm-svn: 220383
If a templated class is not instantiated, then the AST for it could be missing
some things that would throw the field checker off. Wait until specialization
before emitting these warnings.
llvm-svn: 220363
This renames the Windows toolchain to MSVCToolChain. This is a preparatory step
for adding a CrossWindowsToolChain which uses clang/libc++/(ld/lld) without the
standard GCC toolchain lookup. NFC.
llvm-svn: 220362
Implicit module builds are not well-suited to a lot of build systems. In
particular, they fare badly in distributed build systems, and they lead to
build artifacts that are not tracked as part of the usual dependency management
process. This change allows explicitly-built module files (which are already
supported through the -emit-module flag) to be explicitly loaded into a build,
allowing build systems to opt to manage module builds and dependencies
themselves.
This is only the first step in supporting such configurations, and it should
be considered experimental and subject to change or removal for now.
llvm-svn: 220359
complete object to a pointer to the start of another complete object does
not evaluate to the constant 'false'. All other comparisons between the
addresses of subobjects of distinct complete objects still do.
llvm-svn: 220343
-g1 on gcc (and also IBM's xlc) are documented to be very similar to
-gline-tables-only. Our -gline-tables-only might still be more verbose than -g1
on other compilers, but currently we treat -g1 as -g, and so we're producing
much more debug info at -g1 than everybody else. Treating -g1 as
-gline-tables-only brings us much closer to what everyone else is doing.
For more information, see the discussion on
http://lists.cs.uiuc.edu/pipermail/cfe-dev/2014-October/039649.html
llvm-svn: 220311
This fixes crash report generation when filenames have spaces. It also
removes an awkward workaround that quoted *some* arguments when
generating crash reports.
llvm-svn: 220307
This pushes the logic for generating a crash reproduction script
entirely into Command::Print, instead of Command doing half of the
work and then relying on textual substitution for the rest. This makes
this logic much easier to read and will simplify fixing a couple of
issues in this area.
llvm-svn: 220305
Before:
@SuppressWarnings(
value = "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa") public static int iiiiiiiiiiiiiiiiiiiiiiii;
After:
@SuppressWarnings(value = "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa")
public static int iiiiiiiiiiiiiiiiiiiiiiii;
llvm-svn: 220284
This patch generates some helper variables which used as a private copies of the corresponding original variables inside an OpenMP 'parallel' directive. These generated variables are initialized by default (with the default constructor, if any). In outlined function references to original variables are replaced by the references to these private helper variables. At the end of the initialization of the private variables and implicit barier is set by calling __kmpc_barrier(...) runtime function to be sure that all threads were initialized using original values of the variables.
Differential Revision: http://reviews.llvm.org/D4752
llvm-svn: 220262
This is long-since overdue, and matches GCC 5.0. This should also be
backwards-compatible, because we already supported all of C11 as an extension
in C99 mode.
llvm-svn: 220244
In environments where PATH was set to point to the VS installation, Clang would
override that by looking in the registry and finding the latest VS installation.
If the environment is set up to point to a VS installation, that should take
precedence.
Reverting this until we can fix it.
llvm-svn: 220243
List the module cache we use for crashdumps as a tempfile. This
simplifies how we pick up this directory when generating the actual
crash diagnostic and removes some duplicate logic.
llvm-svn: 220241
In practice there's only ever one temporary output file when
generating a crashdump, but even if there were many iterating over
each and creating a duplicate run script for each one wouldn't make
very much sense.
This updates the behaviour to only generate the script once, based on
the first filename.
This should make it more reasonable to generate extra output files to
include in the crashdump going forward, so I've also added a FIXME to
look into doing just that with the extra module crashdump files.
llvm-svn: 220238
We currently use a null FailingCommand when generating crash reports
as an indication that the cause is FORCE_CLANG_DIAGNOSTICS_CRASH, the
environment variable that exists to test crash dumps. This means that
our tests don't actually cover real crashes at all, and adds a more
complicated code path that's only used in the tests.
Instead, we can have the driver synthesize that every command failed
and just call generateCompilationDiagnostics normally.
llvm-svn: 220234
Typically clang finds Visual Studio by the user explicitly setting
up a Visual Studio environment via vcvarsall. But we still try to
behave intelligently and fallback to different methods of finding
Visual Studio when this is not done. This patch improves various
fallback codepaths to make Visual Studio locating more robust.
Specifically, this patch:
* Adds support for searching environment variables for VS 12.0
* Correctly locates include folders for Windows SDK 8.x (this was
previously broken, and would cause clang to error)
* Prefers locating link.exe in the same location as cl.exe. This
is helpful in case another link.exe is in the path earlier than
Visual Studio (e.g. GnuWin32)
* Minor cleanup in the registry reading code to make it more
robust in the presence of long pathnames.
llvm-svn: 220226
Clang supports __restrict__ as a function qualifier, but
DeclaratorChunk::FunctionTypeInfo lacked a field to track the qualifier's
source location (as we do with volatile, etc.). This was the subject of a FIXME
in GetFullTypeForDeclarator (in SemaType.cpp). This should also prove useful as
we add more warnings regarding questionable uses of the restrict qualifier.
There is no significant functional change (except for an improved source range
associated with the err_invalid_qualified_function_type diagnostic fixit
generated by GetFullTypeForDeclarator).
llvm-svn: 220215
Now that we no longer add mappings when there are no local entities,
there is no need to always bump the size of the tables that correspond
to ContinuousRangeMaps.
llvm-svn: 220208
This is a better fix for 'duplicate key' problems in module continuous
range maps (vs what I added in r215810) by not adding any mappings at
all when there are no local entities. Now it also covers selectors,
which were not always being bumped because the record SELECTOR_OFFSET is
not always emitted. I'll back out most of r215810 in a future commit,
since it should no longer be needed.
llvm-svn: 220207
#include_next interacts poorly with modules: it depends on where in the list of
include paths the current file was found. Files covered by module maps are not
found in include search paths when building the module (and are not found in
include search paths when @importing the module either), so this isn't really
meaningful. Instead, we fake up the result that #include_next *should* have
given: find the first path that would have resulted in the given file being
picked, and search from there onwards.
llvm-svn: 220177
This reverts commit r220169 which reverted r220153. However, it also
contains additional changes:
- We may need to add padding *after* we've packed the struct. This
occurs when the aligned next field offset is greater than the new
field's offset. When this occurs, we make the struct packed.
*However*, once packed the next field offset might be less than the
new feild's offset. It is in this case that we might further pad the
struct.
- We would pad structs which were perfectly sized! This behavior is
immensely old. This behavior came from blindly subtracting
NextFieldOffsetInChars from RecordSize. This doesn't take into
account the fact that the struct might have a greater overall
alignment than the last field.
llvm-svn: 220175
This commit caused two tests in LNT to regress. I'm able to reproduce on
any platform and will send reproduction steps to the original commit
log. This should restore the LNT bots that have been failing.
llvm-svn: 220169
a NaN-test prior to the call to the library function.
This should automatically make fastmath (including just non-NaNs) able to avoid
the expensive libcalls and also open the door to more advanced folding in LLVM
based on the rules for complex math.
Two important notes to remember: first is that this isn't yet a proper
limited range mode, it's still just improving the unlimited range mode.
Also, it isn't really perfecet w.r.t. what an unlimited range mode
should be doing because it isn't quite handling the flags produced by
all the operations in the way desirable for that mode, but then neither
is compiler-rt's libcall. When the compiler-rt libcall is improved to
carefully manage flags, the code emitted here should be improved
correspondingly. And it is still a long-term desirable thing to add
a limited range mode to Clang that would be able to use direct math
without library calls here.
Special thanks to Steve Canon for the careful review on this patch and
teaching me about these issues. =D
Differential Revision: http://reviews.llvm.org/D5756
llvm-svn: 220167
This suppresses a common false positive when analyzing libc++.
Along the way, introduce some tests to show this checker actually
works with C++ static_cast<>.
llvm-svn: 220160
Before, ConstStructBuilder::AppendBytes would check packed constraints
prior to padding being added before the field's offset. However, adding
this padding might force our struct to be packed. Because we wouldn't
check *after* adding padding, ConstStructBuilder would be in an
inconsistent state leading to a crash.
This fixes PR21300.
llvm-svn: 220153
This commit changes the way we blacklist global variables in ASan.
Now the global is excluded from instrumentation (either regular
bounds checking, or initialization-order checking) if:
1) Global is explicitly blacklisted by its mangled name.
This part is left unchanged.
2) SourceLocation of a global is in blacklisted source file.
This changes the old behavior, where instead of looking at the
SourceLocation of a variable we simply considered llvm::Module
identifier. This was wrong, as identifier may not correspond to
the file name, and we incorrectly disabled instrumentation
for globals coming from #include'd files.
3) Global is blacklisted by type.
Now we build the type of a global variable using Clang machinery
(QualType::getAsString()), instead of llvm::StructType::getName().
After this commit, the active users of ASan blacklist files
may have to revisit them (this is a backwards-incompatible change).
llvm-svn: 220097
template specialization type dependent, even if it has no dependent template
arguments. I've filed a corresponding bug against the C++ standard.
llvm-svn: 220088
of a member function of a class template that is defined outside the template.
This substitution can actually fail in some weird cases.
llvm-svn: 220085
Hoist the IgnoreParens so that we ignore it around attributes as well in order
to future-proof the code. Addresses Richard's comments for SVN r219974.
llvm-svn: 220053
It broke some builders. I guess it'd be reproducible with --vg.
Failing Tests (3):
Clang :: CXX/except/except.spec/p1.cpp
Clang :: SemaTemplate/instantiate-exception-spec-cxx11.cpp
Clang :: SemaTemplate/instantiate-exception-spec.cpp
llvm-svn: 220038
RecordType->getDecl() which maps to TagType::getDecl() is not a simple
accessor but a loop on redecls in getInterestingTagDecl.
isStructureOrClassType() was calling getDecl() three times performing
three times the work actually required. It is optimized by calling
RT->getDecl() once and reusing the result three times.
llvm-svn: 220033
non-dependent types, in CXXScalarValueInitExprs and in the
nested-name-specifier or template arguments of a DeclRefExpr in particular.
llvm-svn: 220028
This commit changes the way we blacklist functions in ASan, TSan,
MSan and UBSan. We used to treat function as "blacklisted"
and turned off instrumentation in it in two cases:
1) Function is explicitly blacklisted by its mangled name.
This part is not changed.
2) Function is located in llvm::Module, whose identifier is
contained in the list of blacklisted sources. This is completely
wrong, as llvm::Module may not correspond to the actual source
file function is defined in. Also, function can be defined in
a header, in which case user had to blacklist the .cpp file
this header was #include'd into, not the header itself.
Such functions could cause other problems - for instance, if the
header was included in multiple source files, compiled
separately and linked into a single executable, we could end up
with both instrumented and non-instrumented version of the same
function participating in the same link.
After this change we will make blacklisting decision based on
the SourceLocation of a function definition. If a function is
not explicitly defined in the source file, (for example, the
function is compiler-generated and responsible for
initialization/destruction of a global variable), then it will
be blacklisted if the corresponding global variable is defined
in blacklisted source file, and will be instrumented otherwise.
After this commit, the active users of blacklist files may have
to revisit them. This is a backwards-incompatible change, but
I don't think it's possible or makes sense to support the
old incorrect behavior.
I plan to make similar change for blacklisting GlobalVariables
(which is ASan-specific).
llvm-svn: 219997
reverted in r218058 because they triggered a rejects-valid bug in MSVC.
Original commit message from r217995:
Instantiate exception specifications when instantiating function types (other
than the type of a function declaration). We previously didn't instantiate
these at all! This also covers the pathological case where the only mention of
a parameter pack is within the exception specification; this gives us a second
way (other than alias templates) to reach the horrible state where a type
contains an unexpanded pack, but its canonical type does not.
llvm-svn: 219977
A second instance of attributed types escaped the previous change, identified
thanks to Richard Smith! When deducing the void case, we would also assume that
the type would not be attributed. Furthermore, properly handle multiple
attributes being applied to a single TypeLoc.
Properly handle this case and future-proof a bit by ignoring parenthesis
further. The test cases do use the additional parenthesis to ensure that this
case remains properly handled.
Addresses post-commit review comments from Richard Smith to SVN r219851.
llvm-svn: 219974
Summary:
The general approach is to add extra paddings after every field
in AST/RecordLayoutBuilder.cpp, then add code to CTORs/DTORs that poisons the paddings
(CodeGen/CGClass.cpp).
Everything is done under the flag -fsanitize-address-field-padding.
The blacklist file (-fsanitize-blacklist) allows to avoid the transformation
for given classes or source files.
See also https://code.google.com/p/address-sanitizer/wiki/IntraObjectOverflow
Test Plan: run SPEC2006 and some of the Chromium tests with -fsanitize-address-field-padding
Reviewers: samsonov, rnk, rsmith
Reviewed By: rsmith
Subscribers: majnemer, cfe-commits
Differential Revision: http://reviews.llvm.org/D5687
llvm-svn: 219961
They cannot be written to, so marking them const makes sense and may improve
optimisation.
As a side-effect, SectionInfos has to be moved from Sema to ASTContext.
It also fixes this problem, that occurs when compiling ATL:
warning LNK4254: section 'ATL' (C0000040) merged into '.rdata' (40000040) with different attributes
The ATL headers are putting variables in a special section that's marked
read-only. However, Clang currently can't model that read-onlyness in the IR.
But, by making the variables const, the section does become read-only, and
the linker warning is avoided.
Differential Revision: http://reviews.llvm.org/D5812
llvm-svn: 219960
Summary:
Fix code to follow the "Don’t use else after a return" rule.
This is a followup from rL219792.
Reviewers: alexfh
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D5826
llvm-svn: 219939
The final goal is to get rid of all the rest overloads that
accept LLVM objects (llvm::Function and llvm::GlobalVariable),
and pass in source-level entities instead.
llvm-svn: 219937
Plumb through the full QualType of the TemplateArgument::Declaration, as
it's insufficient to only know whether the type is a reference or
pointer (that was necessary for mangling, but insufficient for debug
info). This shouldn't increase the size of TemplateArgument as
TemplateArgument::Integer is still longer by another 32 bits.
Several bits of code were testing that the reference-ness of the
parameters matched, but this seemed to be insufficient (various other
features of the type could've mismatched and wouldn't've been caught)
and unnecessary, at least insofar as removing those tests didn't cause
anything to fail.
(Richard - perchaps you can hypothesize why any of these checks might
need to test reference-ness of the parameters (& explain why
reference-ness is part of the mangling - I would've figured that for the
reference-ness to be different, a prior template argument would have to
be different). I'd be happy to add them in/beef them up and add test
cases if there's a reason for them)
llvm-svn: 219900
Fix for clang crash when instantiating a template with qualified lookup for members in non-class types.
Differential Revision: http://reviews.llvm.org/D5769
llvm-svn: 219897
The functionality contained in CodeGenFunction::EmitAlignmentAssumption has
been moved to IRBuilder (so that it can also be used by LLVM-level code).
Remove this now-duplicate implementation in favor of the IRBuilder code.
llvm-svn: 219877
CodeGen wouldn't mark the aliasee as thread_local if the aliasee was a
tentative definition.
Even if the definition was already emitted, it would never mark the
alias as thread_local.
This fixes PR21288.
llvm-svn: 219859
Soon we'll need to have access to blacklist before the CodeGen
phase (see http://reviews.llvm.org/D5687), so parse and construct
the blacklist earlier.
llvm-svn: 219857
When performing a type deduction from the return type, the FunctionDecl may be
attributed with a calling convention. In such a case, the retrieved type
location may be an AttributedTypeLoc. Performing a castAs<FunctionProtoTypeLoc>
on such a type loc would result in an assertion as they are not derived types.
Ensure that we correctly handle the attributed type location by looking through
it to the modified type loc.
Fixes an assertion triggered in C++14 mode.
llvm-svn: 219851
After http://reviews.llvm.org/D5687 is submitted, we will need
SanitizerBlacklist before the CodeGen phase, so make it a LangOpt
(as it will actually affect ABI / class layout).
llvm-svn: 219842
This change moves SanitizerBlacklist.h from lib/CodeGen
to public Clang headers in include/clang/Basic. SanitizerBlacklist
is currently only used in CodeGen to decide which functions/modules
should be instrumented, but this will soon change as ASan will
optionally modify class layouts during AST construction
(http://reviews.llvm.org/D5687). We need blacklist machinery
to be available at this point.
llvm-svn: 219840
Add a second late template parser callback meant to cleanup any
resources allocated by late template parsing. Call it from the
Sema::ActOnEndOfTranslationUnit method after all pending template
instantiations have been completed. Teach Parser::ParseTopLevelDecl to
install the cleanup callback when incremental processing is enabled so
that Parser::TemplateIds can be freed.
Patch by Brad King!
llvm-svn: 219810
In particular, if you have two identical templates in different TUs in
anonymous namespaces, we would use the same global_ctors comdat key for
both. As a result, only one would be run.
llvm-svn: 219806
The size of the ID field in CommandInfo was narrow, leading to potential
wrap-around of command IDs, causing misinterpretation later on.
The patch does the following:
- It extends the ID bitfield from 8 to 20 bits.
- It provides a DRY definition of the number of bits for the field to
avoid using literal numbers in different files.
- It introduces a new assertion that checks for the wrap-around.
- It adds the testcase from PR21254.
llvm-svn: 219802
Summary:
Speed up hasName() matcher by skipping the expensive generation of the
fully qualified name unless we need it.
In the common case of matching an unqualified name, we don't need to
generate the full name. We might not even need to copy any string at
all.
This change speeds up our clang-tidy benchmark by ~10%
Reviewers: klimek
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D5776
llvm-svn: 219792
Unions are initialized with the default initialization of their first
named member. If that member is not zero initialized, then we should
prefer that member's type. Otherwise, we might try to make an otherwise
unsuitable type (like an array) which we cannot easily initialize with a
pointer to member.
llvm-svn: 219781
The various ways to create an ASTUnit all take a refcounted pointer to
a diagnostics engine as an argument, and if it isn't pointing at
anything they initialize it. This is a pretty confusing API, and it
really makes more sense for the caller to initialize the thing since
they control the lifetime anyway.
This fixes the one caller that didn't bother initializing the pointer
and asserts that the argument is initialized.
llvm-svn: 219752
Summary:
AddressSanitizer currently doesn't support this configuration, and binaries
built with it will just get into an infinite loop during startup.
Test Plan: Includes an automated test.
Reviewers: samsonov
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D5764
llvm-svn: 219744
When lazily constructing static member variable declarations (when
the vtable optimization fires and the definition of the type is omitted
(or built later, lazily), but the out of line definition of the static
member is provided and must be described in debug info) ensure we use
the canonical declaration when computing the file, line, etc for that
declaration (rather than the definition, which is also a declaration,
but not the canonical one).
llvm-svn: 219736
Thumb1 has legitimate reasons for preferring 32-bit alignment of types
i1/i8/i16, since the 16-bit encoding of "add rD, sp, #imm" requires #imm to be
a multiple of 4. However, this is a trade-off betweem code size and RAM usage;
the DataLayout string is not the best place to represent it even if desired.
So this patch removes the extra Thumb requirements, hopefully making ARM and
Thumb completely compatible in this respect.
llvm-svn: 219735
Argyrios Kyrtzidis