| Commit message (Collapse) | Author | Age | Files | Lines | 
| ... |  | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
If the C-style type cast is applied to the overloaded
function and the destination type is function type,
then Clang will crash with assertion failure.  For example,
    void foo(int);
    void foo(int, int);
    void bar() {
        typedef void (ft)(int);
        ft p = (ft)foo;
    }
In this case, the overloaded function foo will be cast to
a function type, which should be considered as an error.
But, unfortunately, since the function resolution is using
canonical type, the matched function will be returned, and
result in SEGV.
This patch fixes this issue by removing the assertion and
add some error diagnostics as the one in static_cast.
llvm-svn: 206133
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
declaration is not visible. Previously we didn't find hidden friend names in
this redeclaration lookup, because we forgot to treat it as a redeclaration
lookup. Conversely, we did find some local extern names, but those don't
actually conflict with a namespace-scope using declaration, because the only
conflicts we can get are scope conflicts, not conflicts due to the entities
being members of the same namespace.
llvm-svn: 206011
 | 
| | 
| 
| 
| 
| 
|  | 
code-completion results.
llvm-svn: 205917
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
This patch adds support for the msvc pragmas section, bss_seg, code_seg, 
const_seg and data_seg as well as support for __declspec(allocate()).
Additionally it corrects semantics and adds diagnostics for 
__attribute__((section())) and the interaction between the attribute 
and the msvc pragmas and declspec.  In general conflicts should now be 
well diganosed within and among these features.
In supporting the pragmas new machinery for uniform lexing for 
msvc pragmas was introduced.  The new machinery always lexes the 
entire pragma and stores it on an annotation token.  The parser 
is responsible for parsing the pragma when the handling the 
annotation token.
There is a known outstanding bug in this implementation in C mode.  
Because these attributes and pragmas apply _only_ to definitions, we 
process them at the time we detect a definition.  Due to tentative 
definitions in C, we end up processing the definition late.  This means 
that in C mode, everything that ends up in a BSS section will end up in 
the _last_ BSS section rather than the one that was live at the time of 
tentative definition, even if that turns out to be the point of actual 
definition.  This issue is not known to impact anything as of yet 
because we are not aware of a clear use or use case for #pragma bss_seg 
but should be fixed at some point.
Differential Revision=http://reviews.llvm.org/D3065#inline-16241 
llvm-svn: 205810
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
It is very similar to GCC's __PRETTY_FUNCTION__, except it prints the
calling convention.
Reviewers: majnemer
Differential Revision: http://reviews.llvm.org/D3311
llvm-svn: 205780
 | 
| | 
| 
| 
| 
| 
|  | 
it is subsumed by r205521.
llvm-svn: 205718
 | 
| | 
| 
| 
|  | 
llvm-svn: 205715
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
which warns on compound conditionals that always evaluate to the same value.
For instance, (x > 5 && x < 3) will always be false since no value for x can
satisfy both conditions.
This patch also changes the CFG to use these tautological values for better
branch analysis.  The test for -Wunreachable-code shows how this change catches
additional dead code.
Patch by Anders Rönnholm.
llvm-svn: 205665
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
obviously won't work. Specifically, don't suggest methods (static or
not) from unrelated classes when the expression is a method call
through a specific object.
llvm-svn: 205653
 | 
| | 
| 
| 
| 
| 
|  | 
with -Wconversion. // rdar://16502418
llvm-svn: 205646
 | 
| | 
| 
| 
| 
| 
|  | 
involving capabilities, the semantics for attributes now looks through the types of the constituent parts of a capability expression instead of at the aggregate expression type.
llvm-svn: 205629
 | 
| | 
| 
| 
|  | 
llvm-svn: 205620
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
better.  This warning will now trigger on the following conditionals:
bool b;
int i;
if (b > 1) {}  // always false
if (0 <= (i > 5)) {} // always true
if (-1 > b) {} // always false
Patch by Per Viberg.
llvm-svn: 205608
 | 
| | 
| 
| 
| 
| 
| 
|  | 
as there is no way to attach this attribute to the
block literal. // rdar://16274746
llvm-svn: 205580
 | 
| | 
| 
| 
| 
| 
| 
|  | 
(which indicates vector expression is a string of hex
values) instead of crashing in code gen. // rdar://16492792
llvm-svn: 205557
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
No functionality change.
When determining the pattern for instantiating a generic lambda call operator specialization - we must not go drilling down for the 'prototype' (i.e. as written) pattern - rather we must use our partially transformed  pattern (whose DeclRefExprs are wired correctly to any enclosing lambda's decls that should be mapped correctly in a local instantiation scope) that is the templated pattern of the specialization's primary template (even though the primary template might be instantiated from a 'prototype' member-template).  Previously, the drilling down was haltted by marking the instantiated-from primary template as a member-specialization (incorrectly). 
This prompted Richard to remark (http://llvm-reviews.chandlerc.com/D1784?id=4687#inline-10272) 
"It's a bit nasty to (essentially) set this bit incorrectly. Can you put the check into getTemplateInstantiationPattern instead?"
In my reckless youth, I chose to ignore that comment.  With the passage of time, I have come to learn the value of bowing to the will of the angry Gods ;) 
llvm-svn: 205543
 | 
| | 
| 
| 
|  | 
llvm-svn: 205521
 | 
| | 
| 
| 
|  | 
llvm-svn: 205506
 | 
| | 
| 
| 
| 
| 
|  | 
to suggest a different syntax to get the same effect.
llvm-svn: 205467
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
meaningful to odr-use the VarDecl inside a variable template. (Separately, it'd
be nice to track referenced-ness for templates, and warn on unused ones, but
that's really a distinct issue...)
Move a test that generates and tests a warning-suppressing error out to its own
test file, so it doesn't have weird effects on the other tests in the same file.
llvm-svn: 205448
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
at ... )')
For namespaces, this is consistent with mangling and GCC's debug info
behavior. For structs, GCC uses <anonymous struct> but we prefer
consistency between all anonymous entities but don't want to confuse
them with template arguments, etc, so we'll just go with parens in all
cases.
llvm-svn: 205398
 | 
| | 
| 
| 
| 
| 
|  | 
Instead of using terminology such as "lock", "unlock" and "locked", the new terminology is "acquire", "release" and "held". Additionally, the capability attribute's name argument is now reported as part of the diagnostic, instead of hard coding as "mutex."
llvm-svn: 205359
 | 
| | 
| 
| 
|  | 
llvm-svn: 205340
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
compareConversionFunctions() on incorrect code.
I'm looking into getting a reduced test case, but it's not
immediately available.
Fixes <rdar://problem/16344806>
llvm-svn: 205285
 | 
| | 
| 
| 
| 
| 
|  | 
on a function.
llvm-svn: 205255
 | 
| | 
| 
| 
|  | 
llvm-svn: 205198
 | 
| | 
| 
| 
| 
| 
| 
|  | 
A redeclaration may not add dllimport or dllexport attributes. dllexport is
sticky and can be omitted on redeclarations while dllimport cannot.
llvm-svn: 205197
 | 
| | 
| 
| 
|  | 
llvm-svn: 205164
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
Summary:
Declaring a function as inline after it has been defined is in violation
of [dcl.fct.spec]p4.  The program would get a strong definition instead
of getting a function with linkonce_odr linkage.
Reviewers: rsmith
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D3220
llvm-svn: 205129
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
This adds Clang support for the ARM64 backend. There are definitely
still some rough edges, so please bring up any issues you see with
this patch.
As with the LLVM commit though, we think it'll be more useful for
merging with AArch64 from within the tree.
llvm-svn: 205100
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
intentionally marked dead via if((0)).
Taking a hint from -Wparentheses, use an extra '()' as a sigil that
a dead condition is intentionally dead.  For example:
  if ((0)) { dead }
When this sigil is found, do not emit a dead code warning.  When the
analysis sees:
  if (0)
it suggests inserting '()' as a Fix-It.
llvm-svn: 205069
 | 
| | 
| 
| 
| 
| 
|  | 
Reviewed at http://llvm-reviews.chandlerc.com/D3096
llvm-svn: 205008
 | 
| | 
| 
| 
| 
| 
| 
|  | 
an opt-in option under -Wselector-type-mismatch.
// rdar://16445728
llvm-svn: 204965
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
This commit also adds an additional test case for the global destructor warning.
Reviewed in http://llvm-reviews.chandlerc.com/D3205
llvm-svn: 204954
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
|  | 
cannot be a pointer to the private address space (as clarified
in the OpenCL 1.2 specification).
Patch by Fraser Cormack!
llvm-svn: 204941
 | 
| | 
| 
| 
| 
| 
|  | 
the type of the variable until it's known.
llvm-svn: 204887
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
selectors because we were not going through entire
elements in list of all implemented selectors. 
// rdar://16428638
llvm-svn: 204852
 | 
| | 
| 
| 
| 
| 
|  | 
Fixes PR19253.
llvm-svn: 204825
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
The main difference between __va_start and __builtin_va_start is that
the address of the va_list has already been taken, and the va_list is
always a char*.
__va_end and __va_arg are not needed.
llvm-svn: 204821
 | 
| | 
| 
| 
| 
| 
|  | 
in a lambda capture.
llvm-svn: 204757
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
|  | 
If there are any scope specifiers, then a base class must be named or
the symbol isn't from a base class.
Fixes PR19233.
llvm-svn: 204753
 | 
| | 
| 
| 
| 
| 
|  | 
as a structure declaration. This allows for C code to use Boolean expressions on a capability as part of another attribute. Eg) __attribute__((requires_capability(!SomeCapability)))
llvm-svn: 204657
 | 
| | 
| 
| 
| 
| 
| 
|  | 
dllimport implies a definition which means the 'extern' keyword is optional
when declaring imported variables.
llvm-svn: 204576
 | 
| | 
| 
| 
|  | 
llvm-svn: 204569
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
found with a smarter version of -Wunused-member-function that I'm playwing with.
Appologies in advance if I removed someone's WIP code.
 ARCMigrate/TransProperties.cpp                  |    8 -----
 AST/MicrosoftMangle.cpp                         |    1 
 Analysis/AnalysisDeclContext.cpp                |    5 ---
 Analysis/LiveVariables.cpp                      |   14 ----------
 Index/USRGeneration.cpp                         |   10 -------
 Sema/Sema.cpp                                   |   33 +++++++++++++++++++++---
 Sema/SemaChecking.cpp                           |    3 --
 Sema/SemaDecl.cpp                               |   20 ++------------
 StaticAnalyzer/Checkers/GenericTaintChecker.cpp |    1 
 9 files changed, 34 insertions(+), 61 deletions(-)
llvm-svn: 204561
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
specialization from a module. (This can also happen for function template
specializations in PCHs if they're instantiated eagerly, because they're
constexpr or have a deduced return type.)
llvm-svn: 204547
 | 
| | 
| 
| 
| 
| 
|  | 
appropriate place, so that we only ask the external source once.
llvm-svn: 204535
 | 
| | 
| 
| 
| 
| 
|  | 
performing typo correction on very short (1 or 2 char) identifiers.
llvm-svn: 204525
 | 
| | 
| 
| 
|  | 
llvm-svn: 204524
 | 
| | 
| 
| 
| 
| 
|  | 
NUM_OPENMP_DEFAULT_KINDS <= 1.
llvm-svn: 204487
 |