| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
No functionality change.
llvm-svn: 176469
|
| |
|
|
|
|
|
|
|
| |
and be sure to apply them whether or not the debugger gave
us a method declaration.
rdar://12565338
llvm-svn: 176432
|
| |
|
|
|
|
|
|
| |
to a subscript operator.
rdar://13332183
llvm-svn: 176428
|
| |
|
|
|
|
| |
we are looking at.
llvm-svn: 176414
|
| |
|
|
|
|
| |
These all appear in comments or (ironically) diagnostics output.
llvm-svn: 176383
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
whether we already have a method. Fixes a bug where we were
failing to properly contextually convert a message receiver
during template instantiation.
As a side-effect, we now actually perform correct method lookup
after adjusting a message-send to integral or non-ObjC pointer
types (legal outside of ARC).
rdar://13305374
llvm-svn: 176339
|
| |
|
|
|
|
|
|
|
|
|
| |
of block declarators. Document the rule we use.
Also document the rule that Doug implemented a few weeks ago
which drops ownership qualifiers on function result types.
rdar://10127067
llvm-svn: 176336
|
| |
|
|
|
|
|
|
| |
have their own code completion comments. Use those in
their properties in this case.
// rdar://12791315
llvm-svn: 176271
|
| |
|
|
|
|
| |
template parameter
llvm-svn: 176216
|
| |
|
|
|
|
|
|
| |
access to a private member to which we have special access.
rdar://12926092
llvm-svn: 176146
|
| |
|
|
| |
llvm-svn: 176122
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This would error in C++ mode unless the variable also had a cv
qualifier.
e.g.
__attribute__((address_space(2))) float foo = 1.0f; would error but
__attribute__((address_space(2))) const float foo = 1.0f; would not.
llvm-svn: 176121
|
| |
|
|
|
|
| |
macros.
llvm-svn: 176114
|
| |
|
|
|
|
|
|
|
|
| |
GCC applies a pragma weak to a decl if it matches the mangled name. We used
to apply if it matched the plain name.
This patch is a compromise: we apply the pragma only if it matches the name
and the decl has C language linkage.
llvm-svn: 176110
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These are two related changes (one in llvm, one in clang).
LLVM:
- rename address_safety => sanitize_address (the enum value is the same, so we preserve binary compatibility with old bitcode)
- rename thread_safety => sanitize_thread
- rename no_uninitialized_checks -> sanitize_memory
CLANG:
- add __attribute__((no_sanitize_address)) as a synonym for __attribute__((no_address_safety_analysis))
- add __attribute__((no_sanitize_thread))
- add __attribute__((no_sanitize_memory))
for S in address thread memory
If -fsanitize=S is present and __attribute__((no_sanitize_S)) is not
set llvm attribute sanitize_S
llvm-svn: 176076
|
| |
|
|
|
|
|
|
|
|
|
|
| |
consumer
just using ASTConsumer::HandleCXXStaticMemberVarInstantiation(), don't pass it with
ASTConsumer::HandleTopLevelDecl.
ASTConsumer::HandleTopLevelDecl is intended for user-written top-level decls;
a consumer can treat an instantiated static data member however it wants of course.
llvm-svn: 175976
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Use Optional<CFG*> where invalid states were needed previously. In the one case
where that's not possible (beginAutomaticObjDtorsInsert) just use a dummy
CFGAutomaticObjDtor.
Thanks for the help from Jordan Rose & discussion/feedback from Ted Kremenek
and Doug Gregor.
Post commit code review feedback on r175796 by Ted Kremenek.
llvm-svn: 175938
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Weather we should give C language linkage to functions and variables with
internal linkage probably depends on how much code assumes it. The standard
says they should have no language linkage, but gcc and msvc assign them
C language linkage.
This commit removes the hack that was preventing the mangling on static
functions declare in extern C contexts. It is an experiment to see if we
can implement the rules in the standard.
If it turns out that many users depend on these functions and variables
having C language linkage, we should change isExternC instead and try
to convince the CWG to change the standard.
llvm-svn: 175937
|
| |
|
|
| |
llvm-svn: 175936
|
| |
|
|
|
|
|
| |
c++'s named cast need be replaced for bridge casting.
// rdar://12788838
llvm-svn: 175923
|
| |
|
|
| |
llvm-svn: 175912
|
| |
|
|
|
|
| |
internal linkage.
llvm-svn: 175903
|
| |
|
|
|
|
|
|
| |
Introduce a new AST Decl node "EmptyDecl" to model empty-declaration. Have attributes from attribute-declaration appertain
to the EmptyDecl node by creating the AST representations of these attributes and attach them to the EmptyDecl node so these
attributes can be sema checked just as attributes attached to "normal" declarations.
llvm-svn: 175900
|
| |
|
|
|
|
| |
PrintTemplateArgumentList.
llvm-svn: 175894
|
| |
|
|
|
|
| |
Patch by Alexander Zinenko!
llvm-svn: 175890
|
| |
|
|
|
|
| |
incomplete type.
llvm-svn: 175880
|
| |
|
|
| |
llvm-svn: 175875
|
| |
|
|
|
|
|
|
|
| |
ignore invalid declarations.
This reduces the "ambiguous reference" errors (which are rather strange in C/ObjC) and fixes an assertion hit
with an invalid code test case.
llvm-svn: 175869
|
| |
|
|
|
|
|
|
| |
function,
instead of a non-function type.
llvm-svn: 175868
|
| |
|
|
| |
llvm-svn: 175867
|
| |
|
|
|
|
|
|
| |
the normal attribute-merging path, because we can't merge alignment attributes
without knowing the complete set of alignment attributes which apply to a
particular declaration.
llvm-svn: 175861
|
| |
|
|
| |
llvm-svn: 175860
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
accessible in its declaring class; otherwise we might
fail to apply [class.protected] when considering
accessibility in derived classes.
Noticed by inspection; <rdar://13270329>.
I had an existing test wrong. Here's why it's wrong:
Follow the rules (and notation) of [class.access]p5.
The naming class (N) is B and the context (R) is D::getX.
- 'x' as a member of B is protected, but R does not occur
in a member or friend of a class derived from B.
- There does exist a base class of B, A, which is accessible
from R, and 'x' is accessible at R when named in A because
'x' as a member of A is protected and R occurs in a member
of a class, D, that is derived from A; however, by
[class.protected], the class of the object expression must
be equal to or derived from that class, and A does not
derive from D.
llvm-svn: 175858
|
| |
|
|
|
|
|
| |
casts with c++ named casts. Change notes to say use
bridge with c-style cast instead. // rdar://12788838
llvm-svn: 175850
|
| |
|
|
| |
llvm-svn: 175807
|
| |
|
|
|
|
|
|
| |
Along the way, improve a diagnostic for "previous declaration here" for implicit parameters.
Fixes <rdar://problem/13211384>.
llvm-svn: 175802
|
| |
|
|
|
|
| |
See r175462 for another example/more details.
llvm-svn: 175796
|
| |
|
|
| |
llvm-svn: 175734
|
| |
|
|
|
|
|
| |
This is a precursor to making Optional<T>'s operator bool 'explicit' when
building Clang & LLVM as C++11.
llvm-svn: 175722
|
| |
|
|
| |
llvm-svn: 175705
|
| |
|
|
|
|
| |
s/ParseMSInlineAsm/parseMSInlineAsm/
llvm-svn: 175680
|
| |
|
|
|
|
| |
Post-commit CR feedback from Jordan Rose regarding r175594.
llvm-svn: 175679
|
| |
|
|
|
|
|
| |
diagnose attributes on alias declarations, using directives, and attribute
declarations.
llvm-svn: 175649
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
control the visibility of a type for the purposes of RTTI
and template argument restrictions independently of how
visibility propagates to its non-type member declarations.
Also fix r175326 to not ignore template argument visibility
on a template explicit instantiation when a member has
an explicit attribute but the instantiation does not.
The type_visibility work is rdar://11880378
llvm-svn: 175587
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MacroInfo class
for the data specific to a macro definition (e.g. what the tokens are), and
MacroDirective class which encapsulates the changes to the "macro namespace"
(e.g. the location where the macro name became active, the location where it was undefined, etc.)
(A MacroDirective always points to a MacroInfo object.)
Usually a macro definition (MacroInfo) is where a macro name becomes active (MacroDirective) but
splitting the concepts allows us to better model the effect of modules to the macro namespace
(also as a bonus it allows better modeling of push_macro/pop_macro #pragmas).
Modules can have their own macro history, separate from the local (current translation unit)
macro history; MacroDirectives will be used to model the macro history (changes to macro namespace).
For example, if "@import A;" imports macro FOO, there will be a new local MacroDirective created
to indicate that "FOO" became active at the import location. Module "A" itself will contain another
MacroDirective in its macro history (at the point of the definition of FOO) and both MacroDirectives
will point to the same MacroInfo object.
Introducing the separation of macro concepts is the first part towards better modeling of module macros.
llvm-svn: 175585
|
| |
|
|
|
|
|
|
| |
attributes yet, so just issue the appropriate diagnostics. Also generalize the
fixit for attributes-in-the-wrong-place code and reuse it here, if attributes
are placed after the access-specifier or 'virtual' in a base specifier.
llvm-svn: 175575
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The TypeLoc hierarchy used the llvm::cast machinery to perform undefined
behavior by casting pointers/references to TypeLoc objects to derived types
and then using the derived copy constructors (or even returning pointers to
derived types that actually point to the original TypeLoc object).
Some context is in this thread:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-December/056804.html
Though it's spread over a few months which can be hard to read in the mail
archive.
llvm-svn: 175462
|
| |
|
|
|
|
| |
a small test case). // rdar://13178483.
llvm-svn: 175450
|
| |
|
|
| |
llvm-svn: 175331
|
| |
|
|
| |
llvm-svn: 175289
|