This also provides isConst/Volatile/Restrict on FunctionTypes to coalesce
the implementation with other callers (& update those other callers).
Patch contributed by Sam Panzer (panzer@google.com).
llvm-svn: 161647
This is effectively a warning for code that violates core issue 903 & thus will
become standard error in the future, hopefully. It catches strange null
pointers such as: '\0', 1 - 1, const int null = 0; etc...
There's currently a flaw in this warning (& the warning for 'false' as a null
pointer literal as well) where it doesn't trigger on comparisons (ptr == '\0'
for example). Fix to come in a future patch.
Also, due to this only being a warning, not an error, it triggers quite
frequently on gtest code which tests expressions for null-pointer-ness in a
SFINAE context (so it wouldn't be a problem if this was an error as in an
actual implementation of core issue 903). To workaround this for now, the
diagnostic does not fire in unevaluated contexts.
Review by Sean Silva and Richard Smith.
llvm-svn: 161501
update implementation to match. An elidable, non-trivial constructor call is a
side-effect under this definition, but wasn't under the old one, because we are
not required to evaluate it even though it may have an effect.
Also rationalize checking for volatile reads: just look for lvalue-to-rvalue
conversions on volatile glvalues, and ignore whether a DeclRefExpr etc is for
a volatile variable.
llvm-svn: 161393
was mistakenly classifying dynamic_casts which might throw as having no side
effects.
Switch it from a visitor to a switch, so it is kept up-to-date as future Expr
nodes are added. Move it from ExprConstant.cpp to Expr.cpp, since it's not
really related to constant expression evaluation.
Since we use HasSideEffect to determine whether to emit an unused global with
internal linkage, this has the effect of suppressing emission of globals in
some cases.
I've left many of the Objective-C cases conservatively assuming that the
expression has side-effects. I'll leave it to someone with better knowledge
of Objective-C than mine to improve them.
llvm-svn: 161388
Doxygen manual claims that multiple \brief or \returns commands will be merged
together, but actual behavior is different (second \brief command becomes a
part of a discussion, second \returns becomes a "Returns: blah" paragraph on
its own). Anyway, it seems to be a bad idea to use multiple \brief or \returns
commands in a single command.
llvm-svn: 161325
This only applies in the case where ->* is not overloaded, since it
specifically looks for BinaryOperator and not CXXOperatorCallExpr.
llvm-svn: 161275
By C++ standard, the vtable should be generated if the first non-inline
virtual function is defined in the TU. Current version of clang doesn't
generate vtable if the first virtual function is defaulted, because the
key function is regarded as the defaulted function.
Patch by Li Kan!
llvm-svn: 161236
The only caveat is renumbering CXCommentKind enum for aesthetic reasons -- this
breaks libclang binary compatibility, but should not be a problem since API is
so new.
This also fixes PR13372 as a side-effect.
llvm-svn: 161087
When performing the simplistic overload resolution for single-argument methods,
don't check the best overload for ambiguity with itself when the best overload
doesn't happen to be the first one.
Fixes PR13480.
llvm-svn: 160961
hex: ) during comment parsing.
Now internal representation of plain text in comment AST does not contain
character references, but the characters themselves.
llvm-svn: 160891
Also, fix a subtle bug, which occurred due to lookupPrivateMethod
defined in DeclObjC.h not looking up the method inside parent's
categories.
Note, the code assumes that Class's parent object has the same methods
as what's in the Root class of a the hierarchy, which is a heuristic
that might not hold for hierarchies which do not descend from NSObject.
Would be great to fix this in the future.
llvm-svn: 160885
a defaulted special member function until the exception specification is needed
(using the same criteria used for the delayed instantiation of exception
specifications for function temploids).
EST_Delayed is now EST_Unevaluated (using 1330's terminology), and, like
EST_Uninstantiated, carries a pointer to the FunctionDecl which will be used to
resolve the exception specification.
This is enabled for all C++ modes: it's a little faster in the case where the
exception specification isn't used, allows our C++11-in-C++98 extensions to
work, and is still correct for C++98, since in that mode the computation of the
exception specification can't fail.
The diagnostics here aren't great (in particular, we should include implicit
evaluation of exception specifications for defaulted special members in the
template instantiation backtraces), but they're not much worse than before.
Our approach to the problem of cycles between in-class initializers and the
exception specification for a defaulted default constructor is modified a
little by this change -- we now reject any odr-use of a defaulted default
constructor if that constructor uses an in-class initializer and the use is in
an in-class initialzer which is declared lexically earlier. This is a closer
approximation to the current draft solution in core issue 1351, but isn't an
exact match (but the current draft wording isn't reasonable, so that's to be
expected).
llvm-svn: 160847
Rather than adding a ContainsUnexpandedParameterPack bit to essentially every
AST node, we tunnel the bit directly up to the surrounding lambda expression
when we reach a context where an unexpanded pack can not normally appear.
Thus any statement or declaration within a lambda can now potentially contain
an unexpanded parameter pack.
llvm-svn: 160705
structor class under ARC, that struct/class does not have a trivial
move constructor or move assignment operator. Fixes the rest of
<rdar://problem/11738725>.
llvm-svn: 160615
The assertion was wrong in case we have a verbatim block without a closing
command.
Also add tests for closing command name in a verbatim block, since now it can
be empty in such cases.
llvm-svn: 160568
despite __attribute__(__used__). As explained by Argyrios,
> .a archive files do some stripping of their own and they remove .o files that
> contain functions that are not referenced by any other .o file.
The fix is to use these functions from another .o file.
Thanks, Argyrios!
llvm-svn: 160437
given declaration.
It is based on the observation that during parsing the comment that should be
attached to the decl is usually among the last two documentation comments
parsed.
llvm-svn: 160400
being a property of a canonical type to being a property of the fully-sugared
type. This should only make a difference in the case where an alias template
ignores one of its parameters, and that parameter is an unexpanded parameter
pack.
llvm-svn: 160244
AVX). Currently, if no aligned attribute is specified the alignment of a vector is
inferred from its size. Thus, very large vectors will be over-aligned with no
benefit. Target owners should set this target max.
llvm-svn: 160209
to the same signature. Fix a bug in the type printer which would cause this
diagnostic to print wonderful types like 'const const int *'.
llvm-svn: 160161
diagnostics implemented -- see testcases.
I created a new TableGen file for comment diagnostics,
DiagnosticCommentKinds.td, because comment diagnostics don't logically
fit into AST diagnostics file. But I don't feel strongly about it.
This also implements support for self-closing HTML tags in comment
lexer and parser (for example, <br />).
In order to issue precise diagnostics CommentSema needs to know the
declaration the comment is attached to. There is no easy way to find a decl by
comment, so we match comments and decls in lockstep: after parsing one
declgroup we check if we have any new, not yet attached comments. If we do --
then we do the usual comment-finding process.
It is interesting that this automatically handles trailing comments.
We pick up not only comments that precede the declaration, but also
comments that *follow* the declaration -- thanks to the lookahead in
the lexer: after parsing the declgroup we've consumed the semicolon
and looked ahead through comments.
Added -Wdocumentation-html flag for semantic HTML errors to allow the user to
disable only HTML warnings (but not HTML parse errors, which we emit as
warnings in -Wdocumentation).
llvm-svn: 160078
multidimensional array of class type. Also, preserve zero-initialization when
evaluating an initializer list for an array, in case the initializers refer to
later elements (which have preceding zero-initialization).
llvm-svn: 159904
currently we take address of std::vector's contents only after we finished
adding all comments (so no reallocation can happen), this will change in
future.
llvm-svn: 159845
very simple semantic analysis that just builds the AST; minor changes for lexer
to pick up source locations I didn't think about before.
Comments AST is modelled along the ideas of HTML AST: block and inline content.
* Block content is a paragraph or a command that has a paragraph as an argument
or verbatim command.
* Inline content is placed within some block. Inline content includes plain
text, inline commands and HTML as tag soup.
llvm-svn: 159790
This required moving the ctors for IntegerLiteral and FloatingLiteral out of
line which shouldn't change anything as they are usually called through Create
methods that are already out of line.
ASTContext::Deallocate has been a nop for a long time, drop it from ASTVector
and make it independent from ASTContext.h
Pass the StorageAllocator directly to AccessedEntity so it doesn't need to
have a definition of ASTContext around.
llvm-svn: 159718
attached to a declaration in the completion string.
Since extracting comments isn't free, a new code completion option is
introduced.
A new code completion option that enables including brief comments
into CodeCompletionString should be a, err, code completion option.
But because ASTUnit caches global declarations during parsing before
even completion consumer is created, the option is duplicated as a
translation unit option (in both libclang and ASTUnit, like the option
to cache code completion results).
llvm-svn: 159539
For some targets a structure named __va_list_tag is built to help define
the __builtin_va_list type. However, __va_list_tag was not being treated as a
predefined type thus causing problems when serializing the AST. This commit
fixes that oversight by adding the necessary support to treat __va_list_tag
as a predefined type.
llvm-svn: 159508
This behaves like the existing GNU __alignof and C++11 alignof keywords;
most of the patch is simply adding the third token spelling to various places.
llvm-svn: 159494
Update the two function overloads
void TemplateSpecializationType::PrintTemplateArgumentList(raw_ostream &OS,....
to behave like
std::string TemplateSpecializationType::PrintTemplateArgumentList(const TemplateArgument *Args,...
hence making sure that clang consistently adds a space between two '>' at the end of nested template arguments.
llvm-svn: 159412
the correct this pointer. There is some potential for sharing a bit more
code with canDevirtualizeMemberFunctionCalls, but that can be done in an
independent patch.
llvm-svn: 159326
comparison between two templated types when they both appear in a diagnostic.
Type elision will remove indentical template arguments, which can be disabled
with -fno-elide-type. Cyan highlighting is applied to the differing types.
For more formatting, -fdiagnostic-show-template-tree will output the template
type as an indented text tree, with differences appearing inline. Template
tree works with or without type elision.
llvm-svn: 159216
to see if we had an underlying final class or method, but we would then
use the cast type to do the call, resulting in a direct call to the wrong
method.
llvm-svn: 159212
literal helper functions. All helper functions (global
and locals) use block_invoke as their prefix. Local literal
helper names are prefixed by their enclosing mangled function
names. Blocks in non-local initializers (e.g. a global variable
or a C++11 field) are prefixed by their mangled variable name.
The descriminator number added to end of the name starts off
with blank (for first block) and _<N> (for the N+2-th block).
llvm-svn: 159206
constexpr function evaluation, and corresponding ASan / valgrind issue in
tests, by storing the corresponding value with the relevant stack frame. This
also prevents re-evaluation of the source of the underlying OpaqueValueExpr,
which makes a major performance difference for certain contrived code (see
testcase update).
llvm-svn: 159189
Heavily based on a patch from
Aaron Wishnick <aaron.s.wishnick@gmail.com>.
I'll clean up the duplicated function in CodeGen as
a follow-up, later today or tomorrow.
llvm-svn: 159060
express library-level dependencies within Clang.
This is no more verbose really, and plays nicer with the rest of the
CMake facilities. It should also have no change in functionality.
llvm-svn: 158888
places. I've turned this off for the GNU runtimes --- I don't know if
they support weak class import, but it's easy enough for them to opt in.
Also tweak a comment per review by Jordan.
llvm-svn: 158860
That commit added a new library just to hold the RawCommentList. I've
started a discussion on the commit thread about whether that is really
meritted -- it certainly doesn't seem necessary at this stage.
However, the immediate problem is that the AST library has a hard
dependency on the Comment library, but the dependencies were set up
completely backward. In addition to the layering violation, this had an
unfortunate effect if scattering the Comments library dependency
throughout the build system, but inconsistently so -- several parts of
the CMake dependencies were missing and only showed up due to transitive
deps or the fact that the target wasn't being built by tho bots.
It turns out that the Comments library can't (currently) be a well
formed layer *below* the AST library either, as it has an API that
accepts an ASTContext. That parameter is currently unused, so maybe that
was a mistake?
Anyways, it really seems like this is logically part of the AST --
that's the whole point of the ASTContext providing access to it as far
as I can tell -- so I've merged it into the AST library to solve the
immediate layering violation problems and remove some of the churn from
our library dependencies.
llvm-svn: 158807
target Objective-C runtime down to the frontend: break this
down into a single target runtime kind and version, and compute
all the relevant information from that. This makes it
relatively painless to add support for new runtimes to the
compiler. Make the new -cc1 flag, -fobjc-runtime=blah-x.y.z,
available at the driver level as a better and more general
alternative to -fgnu-runtime and -fnext-runtime. This new
concept of an Objective-C runtime also encompasses what we
were previously separating out as the "Objective-C ABI", so
fragile vs. non-fragile runtimes are now really modelled as
different kinds of runtime, paving the way for better overall
differentiation.
As a sort of special case, continue to accept the -cc1 flag
-fobjc-runtime-has-weak, as a sop to PLCompatibilityWeak.
I won't go so far as to say "no functionality change", even
ignoring the new driver flag, but subtle changes in driver
semantics are almost certainly not intended.
llvm-svn: 158793
* Retain comments in the AST
* Serialize/deserialize comments
* Find comments attached to a certain Decl
* Expose raw comment text and SourceRange via libclang
llvm-svn: 158771
The original r158700 caused crashes in the gcc test suite,
g++.abi/vtable3a.C among others. It also caused failures in the libc++
test suite.
llvm-svn: 158749
Note that this is mostly a structural patch that handles the change from the old
spelling style to the new one. One consequence of this is that all AT_foo_bar
enum values have changed to not be based off of the first spelling, but rather
off of the class name, so they are now AT_FooBar and the like (a straw poll on
IRC showed support for this). Apologies for code churn.
Most attributes have GNU spellings as a temporary solution until everything else
is sorted out (such as a Keyword spelling, which I intend to add if someone else
doesn't beat me to it). This is definitely a WIP.
I've also killed BaseCheckAttr since it was unused, and I had to go through
every attribute anyway.
llvm-svn: 158700
method definition that has its '{' attached to the method name without
a space.
With a method like:
-(id)meth{
.....
}
the logic in ObjCMethodDecl that determined the selector locations got
confused because it was initialized based on an end location for '{' but
that end location changed to '}' after the method was finished.
Fix this by having an immutable end location for the declarator and
for getLocEnd() get the end location from the body itself.
Fixes rdar://11659739.
llvm-svn: 158583
- Support mangling virtual function tables (base tables need work on the
ManglerContext interface).
- Correct mangling of local scopes (i.e. functions and C++ methods).
- Replace every llvm_unreachable() for actually-reachable code with a
diagnostic.
llvm-svn: 158376
only using the linkage.
Use and test both, documenting that considering the visibility and linkage
of template parameters is a difference from gcc.
llvm-svn: 158309
We need an efficient mechanism to determine whether a defaulted default
constructor is constexpr, in order to determine whether a class is a literal
type, so keep the incrementally-built form on CXXRecordDecl. Remove the
on-demand computation of same, so that we only have one method for determining
whether a default constructor is constexpr. This doesn't affect correctness,
since default constructor lookup is much simpler than selecting a constructor
for copying or moving.
We don't need a corresponding mechanism for defaulted copy or move constructors,
since they can't affect whether a type is a literal type. Conversely, checking
whether such functions are constexpr can require non-trivial effort, so we defer
such checks until the copy or move constructor is required.
Thus we now only compute whether a copy or move constructor is constexpr on
demand, and only compute whether a default constructor is constexpr in advance.
This is unfortunate, but seems like the best solution.
llvm-svn: 158290
constexpr until we get to the end of the class definition. When that happens,
be sure to remember that the class actually does have a constexpr constructor.
This is a stopgap solution, which still doesn't cover the case of a class with
multiple copy constructors (only some of which are constexpr). We should be
performing constructor lookup when implicitly defining a constructor in order
to determine whether all constructors it invokes are constexpr.
llvm-svn: 158228
The integral APSInt value is now stored in a decomposed form and the backing
store for large values is allocated via the ASTContext. This way its not
leaked as TemplateArguments are never destructed when they are allocated in
the ASTContext. Since the integral data is immutable it is now shared between
instances, making copying TemplateArguments a trivial operation.
Currently getting the integral data out of a TemplateArgument requires creating
a new APSInt object. This is cheap when the value is small but can be expensive
if it's not. If this turns out to be an issue a more efficient accessor could
be added.
llvm-svn: 158150
In addition, I've made the pointer and reference typedef 'void' rather than T*
just so they can't get misused. I would've omitted them entirely but
std::distance likes them to be there even if it doesn't use them.
This rolls back r155808 and r155869.
Review by Doug Gregor incorporating feedback from Chandler Carruth.
llvm-svn: 158104
temporary or an array subobject of a class temporary, and the resulting value
is used to initialize a pointer which outlives the temporary. Such a pointer
is always left dangling after the initialization completes and the array's
lifetime ends.
In order to detect this situation, this change also adds an
LValueClassification of LV_ArrayTemporary for temporaries of array type which
aren't subobjects of class temporaries. These occur in C++11 T{...} and GNU C++
(T){...} expressions, when T is an array type. Previously we treated the former
as a generic prvalue and the latter as a class temporary.
llvm-svn: 157955
pointer, but such folding encounters side-effects, ignore the side-effects
rather than performing them at runtime: CodeGen generates wrong code for
__builtin_object_size in that case.
llvm-svn: 157310
struct HIDDEN foo {
};
template <class P>
struct bar {
};
template <>
struct HIDDEN bar<foo> {
DEFAULT static void zed();
};
void bar<foo>::zed() {
}
Before we would produce a hidden symbol in
struct HIDDEN foo {
};
template <class P>
struct bar {
};
template <>
struct bar<foo> {
DEFAULT static void zed();
};
void bar<foo>::zed() {
}
But adding HIDDEN to the specialization would cause us to produce a default
symbol.
llvm-svn: 157206
Because in CUDA types do not have associated address spaces,
globals are declared in their "native" address space, and accessed
by bitcasting the pointer to address space 0. This relies on address
space 0 being a unified address space.
llvm-svn: 157167
to use the @() boxing syntax.
It will also rewrite uses of stringWithCString:encoding: where the encoding that is
used is NSASCIIStringEncoding or NSUTF8StringEncoding.
rdar://11438360
llvm-svn: 156868
* Don't copy the visibility attribute during instantiations. We have to be able
to distinguish
struct HIDDEN foo {};
template<class T>
DEFAULT void bar() {}
template DEFAULT void bar<foo>();
from
struct HIDDEN foo {};
template<class T>
DEFAULT void bar() {}
template void bar<foo>();
* If an instantiation has an attribute, it takes precedence over an attribute
in the template.
* With instantiation attributes handled with the above logic, we can now
select the minimum visibility when looking at template arguments.
llvm-svn: 156821
it is placed in a position which is never ambiguous with a
reference-to-function type. This follows some recent discussion
and ensuing proposal on cxx-abi-dev. It is not necessary to
change the mangling of CV-qualifiers because you cannot
apply CV-qualification in the normal sense to a function type.
It is not necessary to change the mangling of ref-qualifiers on
method declarations because they appear in an unambiguous
location.
In addition, mangle CV-qualifiers and ref-qualifiers on function
types when they occur in positions other than member pointers
(that is, when they appear as template arguments).
This is a minor ABI break with previous releases of clang. It
is not considered critical because (1) ref-qualifiers are
relatively rare, since AFAIK we're the only implementing compiler,
and (2) they're particularly likely to come up in contexts that
do not rely on the ODR for correctness. We apologize for any
inconvenience; this is the right thing to do.
llvm-svn: 156794
in-class initializer for one of its fields. Value-initialization of such
a type should use the in-class initializer!
The former was just a bug, the latter is a (reported) standard defect.
llvm-svn: 156274
to get a const char* if necessary.
This avoids unnecessary conversions when we want to use the result of getName as
a StringRef.
Part of rdar://10796159
llvm-svn: 156227
that bridging between the two is free. Saves ~4k of code size,
although I don't see any measurable performance difference
(unfortunately).
llvm-svn: 156187
Teach ASTContext about WIntType, and have it taken from TargetInfo like WCharType. Should fix test/Sema/format-strings.c for ARM, with the exception of one subtest which will fail if wint_t and wchar_t are the same size and wint_t is signed, wchar_t is unsigned.
There'll be a followup commit to fix that.
Reviewed by Chandler and Hans at http://llvm.org/reviews/r/8
llvm-svn: 156165
of templates by using the newly introduce FoldingSetVector. This
preserves insertion order for all iteration of specializations.
I've also included a somewhat terrifying testcase that rapidly builds up
a large number of functions. This is enough that any system with ASLR
will have non-deterministic debug information generated for the test
case without the fix here as the debug information is generated in part
by walking these specializations.
llvm-svn: 156133
calculating it recursively.
boost::assign::tuple_list_of uses the trick of chaining call operator expressions in order to declare a "list of tuples", e.g:
std::vector<tuple> v = boost::assign::tuple_list_of(1, "foo")(2, "bar")(3, "qqq");
Due to CXXOperatorCallExpr calculating its source range recursively we would get
significant slowdowns with a large number of chained call operator expressions and the
potential for stack overflow.
rdar://11350116
llvm-svn: 155848
filter_decl_iterator had a weird mismatch where both op* and op-> returned T*
making it difficult to generalize this filtering behavior into a reusable
library of any kind.
This change errs on the side of value, making op-> return T* and op* return
T&.
(reviewed by Richard Smith)
llvm-svn: 155808
- -Wc++98-compat depends on the c++98 definition
- Now __is_pod returns the right thing in c++11 and c++98 mode
- All changes to the type traits test are validated against g++ 4.7
llvm-svn: 155756
the tempale arguments in deciding the visibility.
This agrees with gcc 4.7.
Found by trying to build chrome with component=shared_library with 155314
reverted.
llvm-svn: 155316
This fixes the included testcase and lets us simplify the code a bit. It
does require using mergeWithMin when merging class information to its
members. Expand the comments to explain why that works.
llvm-svn: 155103
there is no need for mergeVisibily to ever increase the visibility. Not
doing so lets us replace an incorrect use of mergeVisibilityWithMin. The
testcase
struct HIDDEN RECT {
int top;
};
DEFAULT RECT foo = {0};
shows that we should give preference to one of the attributes instead of
keeping the minimum. We still get this testcase wrong because mergeVisibily
handles two explicit visibilities incorrectly, but this is a step in the
right direction.
llvm-svn: 155101
the current implementation this should be a nop as explicit visibility
takes precedence in mergeVisibility.
The location chosen is such that attributes checked above it can force
a symbol to be default. For example, an attribute is the variable or function.
Attributes checked after this point, can only make the visibility more
restrictive. An attribute in a type for example.
llvm-svn: 155098
currently a nop as those users are the first merge or are a merge
of a hidden explicit visibility, which always wins in the current
implementation.
llvm-svn: 155095
specifications on member function templates of class templates and other such
nested beasties. Store the function template from which we are to instantiate
an exception specification rather than trying to deduce it. Plus some
additional test cases.
llvm-svn: 155076
We have a new flavor of exception specification, EST_Uninstantiated. A function
type with this exception specification carries a pointer to a FunctionDecl, and
the exception specification for that FunctionDecl is instantiated (if needed)
and used in the place of the function type's exception specification.
When a function template declaration with a non-trivial exception specification
is instantiated, the specialization's exception specification is set to this
new 'uninstantiated' kind rather than being instantiated immediately.
Expr::CanThrow has migrated onto Sema, so it can instantiate exception specs
on-demand. Also, any odr-use of a function triggers the instantiation of its
exception specification (the exception specification could be needed by IRGen).
In passing, fix two places where a DeclRefExpr was created but the corresponding
function was not actually marked odr-used. We used to get away with this, but
don't any more.
Also fix a bug where instantiating an exception specification which refers to
function parameters resulted in a crash. We still have the same bug in default
arguments, which I'll be looking into next.
This, plus a tiny patch to fix libstdc++'s common_type, is enough for clang to
parse (and, in very limited testing, support) all of libstdc++4.7's standard
headers.
llvm-svn: 154886
in the declaration of a non-static member function after the
(optional) cv-qualifier-seq, which in practice means in the exception
specification and late-specified return type.
The new scheme here used to manage 'this' outside of a member function
scope is more general than the Scope-based mechanism previously used
for non-static data member initializers and late-parsesd attributes,
because it can also handle the cv-qualifiers on the member
function. Note, however, that a separate pass is required for static
member functions to determine whether 'this' was used, because we
might not know that we have a static function until after declaration
matching.
Finally, this introduces name mangling for 'this' and for the implicit
'this', which is intended to match GCC's mangling. Independent
verification for the new mangling test case would be appreciated.
Fixes PR10036 and PR12450.
llvm-svn: 154799
Otherwise we would get this error in C++11 mode (because of a recent change):
error: non-type template argument of type 'const _GUID *' is not a constant expression
For code like:
template <const GUID* g = &__uuidof(struct_with_uuid)>
class COM_CLASS { };
llvm-svn: 154790
includes a patch from Matthias Kleine with a regression testcase!
Adds a new iterator 'data_iterator' to OnDiskHashTable which doesn't try to
reconstruct the external_key from the internal_key, which is useful for traits
that don't store enough information to do that mapping in their key. Also
deletes the 'item_iterator' from OnDiskHashTable as dead code.
llvm-svn: 154784
initialize an array of unsigned char. Outside C++11 mode, this bug was benign,
and just resulted in us emitting a constant which was double the required
length, padded with 0s. In C++11, it resulted in us generating an array whose
first element was something like i8 ptrtoint ([n x i8]* @str to i8).
llvm-svn: 154756
attached. Since we do not support any attributes which appertain to a statement
(yet), testing of this is necessarily quite minimal.
Patch by Alexander Kornienko!
llvm-svn: 154723
__atomic_test_and_set, __atomic_clear, plus a pile of undocumented __GCC_*
predefined macros.
Implement library fallback for __atomic_is_lock_free and
__c11_atomic_is_lock_free, and implement __atomic_always_lock_free.
Contrary to their documentation, GCC's __atomic_fetch_add family don't
multiply the operand by sizeof(T) when operating on a pointer type.
libstdc++ relies on this quirk. Remove this handling for all but the
__c11_atomic_fetch_add and __c11_atomic_fetch_sub builtins.
Contrary to their documentation, __atomic_test_and_set and __atomic_clear
take a first argument of type 'volatile void *', not 'void *' or 'bool *',
and __atomic_is_lock_free and __atomic_always_lock_free have an argument
of type 'const volatile void *', not 'void *'.
With this change, libstdc++4.7's <atomic> passes libc++'s atomic test suite,
except for a couple of libstdc++ bugs and some cases where libc++'s test
suite tests for properties which implementations have latitude to vary.
llvm-svn: 154640
This is not quite sufficient for libstdc++'s <atomic>: we still need
__atomic_test_and_set and __atomic_clear, and may need a more complete
__atomic_is_lock_free implementation.
We are also missing an implementation of __atomic_always_lock_free,
__atomic_nand_fetch, and __atomic_fetch_nand, but those aren't needed
for libstdc++.
llvm-svn: 154579
<stdatomic.h> header.
In passing, fix LanguageExtensions to note that C11 and C++11 are no longer
"upcoming standards" but are now actually standardized.
llvm-svn: 154513
The warning this inhibits, -Wobjc-root-class, is opt-in for now. However, all clang unit tests that would trigger
the warning have been updated to use -Wno-objc-root-class. <rdar://problem/7446698>
llvm-svn: 154187
String literals (including unicode ones) can contain non-Unicode codepoints
if they were written using \x or similar. Write those out using \x, but be
careful that the following character can't be misinterpreted as part of the
\x escape sequence. Convert UTF-16 surrogate pairs back to codepoints before
rendering them.
llvm-svn: 154069
number + context) to the point where we initially start defining the
lambda, so that the linkage won't change when that information is made
available. Fixes the assertion in <rdar://problem/11182962>.
Plus, actually mangle the context of lambdas properly.
llvm-svn: 154029
a type specifier and can be combined with unsigned. This allows libstdc++4.7 to
be used with clang in c++98 mode.
Several other changes are still required for libstdc++4.7 to work with clang in
c++11 mode.
llvm-svn: 153999
reference is going to message the setter, the getter, or both.
Having this info on the ObjCPropertyRefExpr node makes it easier for AST
clients (like libclang) to reason about the meaning of the property reference.
[AST/Sema]
-Use 2 bits (with a PointerIntPair) in ObjCPropertyRefExpr to record the above info
-Have ObjCPropertyOpBuilder set the info appropriately.
[libclang]
-When there is an implicit property reference (property syntax using methods)
have clang_getCursorReferenced return a cursor for the method. If the property
reference is going to result in messaging both the getter and the setter choose
to return a cursor for the setter because it is less obvious from source inspection
that the setter is getting called.
The general idea has the seal of approval by John.
rdar://11151621
llvm-svn: 153709
search for the specialization (in a folding set) and, if not found
form a *Decl that is then inserted into that folding set. In rare
cases, the folding set may be reallocated between the search and the
insertion, causing a crash. No test case, because triggering rehashing
consistently in a small test case is not feasible. Fixes
<rdar://problem/11115071>.
llvm-svn: 153575
completion item. For example, if the code completion itself represents
a declaration in a namespace (say, std::vector), then this API
retrieves the cursor kind and name of the namespace (std). Implements
<rdar://problem/11121951>.
llvm-svn: 153545
non-constant value encountered. This allows the evaluator to deduce that
expressions like (x < 5 || true) is equal to true. Previously, it would visit
x and determined that the entire expression is could not evaluated to a
constant.
This fixes PR12318.
llvm-svn: 153226
in vtable layout where virtual methods inherited from virtual bases
could be assigned the same vcall adjustment slot if they shared
a name and parameter signature but differed in their
cv-qualification. The code was already trying to handle this
case, but unfortunately used the ordinary type qualifiers
(which are always empty here) instead of the method qualifiers.
This seems like something that the API should discourage, but
I don't know how to carry that principle out in this instance.
Eliminate this function's need for an ASTContext while we're at it.
This bug affects the ABI, and fixing it brings us into accord with
the Itanium ABI (and GCC's implementation of it), but, obviously,
technically breaks full compatibility with previous releases of Clang.
Just letting you know.
llvm-svn: 153168
Reintroduce lazy name lookup table building, ensuring that the lazy building step
produces the same lookup table that would be built by the eager step.
Avoid building a lookup table for the translation unit outside C++, even in cases
where we can't recover the contents of the table from the declaration chain on
the translation unit, since we're not going to perform qualified lookup into it
anyway. Continue to support lazily building such lookup tables for now, though,
since ASTMerge uses them.
In my tests, this performs very similarly to ToT with r152608 backed out, for C,
Obj-C and C++, and does not suffer from PR10447.
llvm-svn: 152905
This allows us to handle extreme cases of chained binary operators without causing stack
overflow.
The binary operators that are handled with the data recursive evaluator are
comma, logical, or operators that have operands with integral or enumeration type.
Part of rdar://10941790.
llvm-svn: 152819
breaking bootstrap. No test yet: it's quite hard to tickle the failure case.
The specific testcase for this wouldn't be useful for testing anything more
general than a reintroduction of this precise bug in any case.
llvm-svn: 152775
locations for diagnostics we're not going to emit, and don't track the subobject
designator outside C++11 (since we're not going to use it anyway).
This seems to give about a 0.5% speedup on 403.gcc/combine.c, but the results
were sufficiently noisy that I can't reject the null hypothesis.
llvm-svn: 152761
scoped enumeration members. Later uses of an enumeration temploid as a nested
name specifier should cause its instantiation. Plus some groundwork for
explicit specialization of member enumerations of class templates.
llvm-svn: 152750
The deferred lookup table building step couldn't accurately tell which Decls
should be included in the lookup table, and consequently built different tables
in some cases.
Fix this by removing lazy building of DeclContext name lookup tables. In
practice, the laziness was frequently not worthwhile in C++, because we
performed lookup into most DeclContexts. In C, it had a bit more value,
since there is no qualified lookup.
In the place of lazy lookup table building, we simply don't build lookup tables
for function DeclContexts at all. Such name lookup tables are not useful, since
they don't capture the scoping information required to correctly perform name
lookup in a function scope.
The resulting performance delta is within the noise on my testing, but appears
to be a very slight win for C++ and a very slight loss for C. The C performance
can probably be recovered (if it is a measurable problem) by avoiding building
the lookup table for the translation unit.
llvm-svn: 152608
ObjCInterfaceDecl::getReferencedProtocols(), because the iterators are safe to use
even if the caller did not check that the interface is a definition.
llvm-svn: 152597
the diagnostic for assigning to a copied block capture. This has
the pleasant side-effect of letting us special-case the diagnostic
for assigning to a copied lambda capture as well, without introducing
a new non-modifiable enumerator for it.
llvm-svn: 152593
track whether the referenced declaration comes from an enclosing
local context. I'm amenable to suggestions about the exact meaning
of this bit.
llvm-svn: 152491
copy-construction, which Daniel Dunbar reports as giving a 0.75% speedup on
403.gcc/combine.c. The performance differences on my constexpr torture tests
are below the noise floor.
llvm-svn: 152455
- getSourceRange().getBegin() is about as awesome a pattern as .copy().size().
I already killed the hot paths so this doesn't seem to impact performance on my
tests-of-the-day, but it is a much more sensible (and shorter) pattern.
llvm-svn: 152419
- getSourceRange() can be very expensive, we should try to avoid it if at all possible.
In conjunction with the previous commit I measured a ~2% speedup on 403.gcc/combine.c and a 3% speedup on OmniGroupFrameworks/NSBezierPath-OAExtensions.m.
llvm-svn: 152411
- There are probably a lot more of these worth adding, but these are a start at hitting some of the exprs for which getSourceRange().getBegin() is a poor substitute for getLocStart().
llvm-svn: 152410
- On -emit-llvm-only of 403.gcc/combine.c, for example, we make 160k calls to
getTypeInfo but only ever deal with 680 some distinct types.
I saw these speedups (user time):
403.gcc/combine.c -- 3.1%
OmniGroupFrameworks/NSBezierPath-OAExtensions.m -- 3.6%
JavaScriptCore/Interpreter.cpp -- 1.4%
which seems pretty sweet.
I ran some histograms on those compiles and we end up doing a ton of
getTypeInfo() on 'char' and 'int'. I tried splitting out a fast path for builtin
types, but this wasn't a win. Still kinda seems like we could be doing better
here.
llvm-svn: 152377
- This function is not at all free; pass it around along some hot paths instead
of recomputing it deep inside various VarDecl methods.
llvm-svn: 152363
analysis to make the AST representation testable. They are represented by a
new UserDefinedLiteral AST node, which is a sugared CallExpr. All semantic
properties, including full CodeGen support, are achieved for free by this
representation.
UserDefinedLiterals can never be dependent, so no custom instantiation
behavior is required. They are mangled as if they were direct calls to the
underlying literal operator. This matches g++'s apparent behavior (but not its
actual mangling, which is broken for literal-operator-ids).
User-defined *string* literals are now fully-operational, but the semantic
analysis is quite hacky and needs more work. No other forms of user-defined
literal are created yet, but the AST support for them is present.
This patch committed after midnight because we had already hit the quota for
new kinds of literal yesterday.
llvm-svn: 152211
NSNumber, and boolean literals. This includes both Sema and Codegen support.
Included is also support for new Objective-C container subscripting.
My apologies for the large patch. It was very difficult to break apart.
The patch introduces changes to the driver as well to cause clang to link
in additional runtime support when needed to support the new language features.
Docs are forthcoming to document the implementation and behavior of these features.
llvm-svn: 152137
- These functions are both (a) very commonly called and (b) excellent
candidates for CSE in the callers in which they are commonly used.
- That isHalfType() is hot makes me sad, but it is trivially when inlined (and
a huge waste of time when not!!!).
- The extra IsEnumDeclComplete() function is a hack to break the cycle between
Type.h and Decl.h, I'm not sure of how to do this more cleanly, but am open
to ideas.
llvm-svn: 152126
early, since their values can be used in constant expressions in C++11. For
odr-use checking, the opposite change is required, since references are
odr-used whether or not they satisfy the requirements for appearing in a
constant expression.
llvm-svn: 151881
The bug that was caught by Apple's internal buildbots was valid and also showed another bug in my implementation.
These are now fixed, with regression tests added to catch them both (not Darwin-specific).
Original log:
====================
Revert r151638 because it causes assertion hit on PCH creation for Cocoa.h
Original log:
---------------------
Correctly track tags and enum members defined in the prototype of a function, and ensure they are properly scoped.
This fixes code such as:
enum e {x, y};
int f(enum {y, x} n) {
return 0;
}
This finally fixes PR5464 and PR5477.
---------------------
I also reverted r151641 which was enhancement on top of r151638.
====================
llvm-svn: 151712
Original log:
---------------------
Correctly track tags and enum members defined in the prototype of a function, and ensure they are properly scoped.
This fixes code such as:
enum e {x, y};
int f(enum {y, x} n) {
return 0;
}
This finally fixes PR5464 and PR5477.
---------------------
I also reverted r151641 which was enhancement on top of r151638.
llvm-svn: 151667
There's more potential here, but these Exprs aren't used that often so I don't feel like doing heroic bit packing right now.
-8 bytes on every class changed (x86_64).
llvm-svn: 151501
Original log:
When evaluating integer expressions handle logical operators outside
VisitBinaryOperator() to reduce stack pressure for source with huge number
of logical operators.
Fixes rdar://10913206.
llvm-svn: 151464
data members for deleted or user-provided destructors.
Now it's computed in advance, serialize it, and in passing fix all the other
record DefinitionData flags whose serialization was missing.
llvm-svn: 151441
that provides the behavior of the C++11 library trait
std::is_trivially_constructible<T, Args...>, which can't be
implemented purely as a library.
Since __is_trivially_constructible can have zero or more arguments, I
needed to add Yet Another Type Trait Expression Class, this one
handling arbitrary arguments. The next step will be to migrate
UnaryTypeTrait and BinaryTypeTrait over to this new, more general
TypeTrait class.
Fixes the Clang side of <rdar://problem/10895483> / PR12038.
llvm-svn: 151352
* Handle some situations where we should never make a decl more visible,
even when merging in an explicit visibility.
* Handle attributes in members of classes that are explicitly specialized.
Thanks Nico for the report and testing, Eric for the initial review, and dgregor
for the awesome test27 :-)
llvm-svn: 151236
block pointer that returns a block literal which captures (by copy)
the lambda closure itself. Some aspects of the block literal are left
unspecified, namely the capture variable (which doesn't actually
exist) and the body (which will be filled in by IRgen because it can't
be written as an AST).
Because we're switching to this model, this patch also eliminates
tracking the copy-initialization expression for the block capture of
the conversion function, since that information is now embedded in the
synthesized block literal. -1 side tables FTW.
llvm-svn: 151131
arguments. There are two aspects to this:
- Make sure that when marking the declarations referenced in a
default argument, we don't try to mark local variables, both because
it's a waste of time and because the semantics are wrong: we're not
in a place where we could capture these variables again even if it
did make sense.
- When a lambda expression occurs in a default argument of a
function template, make sure that the corresponding closure type is
considered dependent, so that it will get properly instantiated. The
second bit is a bit of a hack; to fix it properly, we may have to
rearchitect our handling of default arguments, parsing them only
after creating the function definition. However, I'd like to
separate that work from the lambdas work.
llvm-svn: 151076
stable mangling, since these lambdas can end up in multiple
translation units. Sema is responsible for deciding when this is the
case, because it's already responsible for choosing the mangling
number.
llvm-svn: 151029
default arguments of function parameters. This simple-sounding task is
complicated greatly by two issues:
(1) Default arguments aren't actually a real context, so we need to
maintain extra state within lambda expressions to track when a
lambda was actually in a default argument.
(2) At the time that we parse a default argument, the FunctionDecl
doesn't exist yet, so lambda closure types end up in the enclosing
context. It's not clear that we ever want to change that, so instead
we introduce the notion of the "effective" context of a declaration
for the purposes of name mangling.
llvm-svn: 151011
name mangling in the Itanium C++ ABI for lambda expressions is so
dependent on context, we encode the number used to encode each lambda
as part of the lambda closure type, and maintain this value within
Sema.
Note that there are a several pieces still missing:
- We still get the linkage of lambda expressions wrong
- We aren't properly numbering or mangling lambda expressions that
occur in default function arguments or in data member initializers.
- We aren't (de-)serializing the lambda numbering tables
llvm-svn: 150982
Chad Rosier