| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
------------------------------------------------------------------------
r155728 | rsmith | 2012-04-27 12:33:05 -0700 (Fri, 27 Apr 2012) | 4 lines
PR12224 (sort of): Diagnose inheriting constructor declarations in C++11 mode.
We do not support IRGen for these, and get some parts of the semantic analysis
wrong.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/cfe/branches/release_31@155731 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154949 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154886 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
| |
type for rewriter project will be BoolTy.
// rdar://11231426.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154861 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154799 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
| |
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!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154723 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
| |
in the wrong namespace scope. Patch by Jonathan Sauer!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154656 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
| |
when BOOL is not of an intergal type when
boolean literals are used. // rdar://11231426
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154619 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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++.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154579 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
| |
non-type template parameter of pointer type is not a constant expression.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154424 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
| |
Richard's feedback, to properly catch non-constant expressions and
type mismatches. Finishes <rdar://problem/11193097>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154407 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- The [class.protected] restriction is non-trivial for any instance
member, even if the access lacks an object (for example, if it's
a pointer-to-member constant). In this case, it is equivalent to
requiring the naming class to equal the context class.
- The [class.protected] restriction applies to accesses to constructors
and destructors. A protected constructor or destructor can only be
used to create or destroy a base subobject, as a direct result.
- Several places were dropping or misapplying object information.
The standard could really be much clearer about what the object type is
supposed to be in some of these accesses. Usually it's easy enough to
find a reasonable answer, but still, the standard makes a very confident
statement about accesses to instance members only being possible in
either pointer-to-member literals or member access expressions, which
just completely ignores concepts like constructor and destructor
calls, using declarations, unevaluated field references, etc.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154248 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
| |
template parameters of pointer, pointer-to-member, or nullptr_t
type in C++11. Fixes PR9700 / <rdar://problem/11193097>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154219 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
to a lockable type from error to warning.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154198 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
| |
root class is intentionally declared.
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>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154187 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
| |
a constant expression' error into a DefaultError ExtWarn, so that it can be
disabled and is suppressed in system headers. libstdc++4.7 contains some such
functions which we currently can't evaluate as constant expressions.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154115 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* s/nonstatic/non-static/ in the diagnostics, since the latter form outvoted
the former by 28-2 in our diagnostics.
* Fix the "use of member in static member function" diagnostic to correctly
detect this situation inside a block or lambda.
* Produce a more specific "invalid use of non-static member" diagnostic for
the case where a nested class member refers to a member of a
lexically-surrounding class.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154073 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This diagnostic seems to be production ready, it's just an oversight that it
wasn't turned on by default.
The test changes are a bit of a mixed bag. Some tests that seemed like they
clearly didn't need to use this behavior have been modified not to use it.
Others that I couldn't be sure about, I added the necessary expected-warnings
to.
It's possible the diagnostic message could be improved to make it clearer that
this warning can be suppressed by using a value that won't lose precision when
converted to the target type (but can still be a floating point literal, such
as "bool b = 1.0;").
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154068 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
| |
or function with internal linkage as a non-type template argument.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154053 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
| |
in arc mode and opted-in with -Wreceiver-is-weak flag.
// rdar://10225276
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154042 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
| |
No test updates: we don't appear to have any test coverage for these diagnostics!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154000 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
| |
explicitly, deleted in all relevant cases, and explain why.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153894 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
| |
move constructor/move assignment operator are not declared, rather than being
defined as deleted, so move operations on the derived class fall back to
copying rather than moving.
If a move operation on the derived class is explicitly defaulted, the
unmovable subobject will be copied instead of being moved.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153883 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153849 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
| |
member function is deleted.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153773 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
in ARC, under the usual reasoning limiting the use of __autoreleasing.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153725 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
braced-initializers. <rdar://problem/11121178>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153703 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153602 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
| |
provide 'fixit' hint when dictionary index
is not of proper type. // rdar://11062080
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153584 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
unscoped enumeration members: an enumerator name which is visible in the
out-of-class definition of a member of a templated class might not actually
exist in the instantiation of that class, if the enumeration is also lexically
defined outside the class definition and is explicitly specialized.
Depending on the result of a CWG discussion, we may have a different resolution
for a class of problems in this area, but this fixes the immediate issue of a
crash-on-invalid / accepts-invalid (depending on +Asserts). Thanks to Johannes
Schaub for digging into the standard wording to find how this case is currently
specified to behave.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153461 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
| |
forward-declared enums aren't /quite/ done yet.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153350 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
| |
a previous declaration if the redeclaration is invalid. That way lies madness.
Fixes a crash-on-invalid reported by Abramo.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153349 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
| |
class template's definition, and for explicit specializations of such enum
members.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153304 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
| |
c-mode to match behavior with void functions in c. Issue
warning with -pedantic. // rdar://11069896
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153200 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153193 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
| |
pointer field declarations in several meta-data.
// rdar://11079898
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153192 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152835 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
| |
Err on the side of brevity and rename (while providing aliases for the original
name) -Wbool-conversions, -Wint-conversions, and -Wvector-conversions for
consistency with constant, literal, string, and sign conversion warnings. And
name the diagnostic groups explicitly while I'm here rather than rewriting the
string in the groups and sema td files.
Curiously, vector-conversion is not under -Wconversion. Perhaps it should be.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152776 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Original commit message:
Provide -Wnull-conversion separately from -Wconversion.
Like GCC, provide a NULL conversion to non-pointer conversion as a separate
flag, on by default. GCC's flag is "conversion-null" which we provide for
cross compatibility, but in the interests of consistency (with
-Wint-conversion, -Wbool-conversion, etc) the canonical Clang flag is called
-Wnull-conversion.
Patch by Lubos Lunak.
Review feedback by myself, Chandler Carruth, and Chad Rosier.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152774 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
| |
Abbreviated commit message:
Provide -Wnull-conversion separately from -Wconversion.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152765 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
| |
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152750 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Like GCC, provide a NULL conversion to non-pointer conversion as a separate
flag, on by default. GCC's flag is "conversion-null" which we provide for
cross compatibility, but in the interests of consistency (with
-Wint-conversion, -Wbool-conversion, etc) the canonical Clang flag is called
-Wnull-conversion.
Patch by Lubos Lunak.
Review feedback by myself, Chandler Carruth, and Chad Rosier.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152745 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152725 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
clearer, and mention the existence of mutable lambdas.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152598 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
| |
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152593 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
| |
This renames the -Wformat-non-standard flag to -Wformat-non-iso,
rewords the current warnings a bit (pointing out that a format string
is not supported by ISO C rather than being "non standard"),
and adds a warning about positional arguments.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152403 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152394 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
| |
and lots of tidying up.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152392 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
starting with an underscore is ill-formed.
Since this rule rejects programs that were using <inttypes.h>'s macros, recover
from this error by treating the ud-suffix as a separate preprocessing-token,
with a DefaultError ExtWarn. The approach of treating such cases as two tokens
is under discussion for standardization, but is in any case a conforming
extension and allows existing codebases to keep building while the committee
makes up its mind.
Reword the warning on the definition of literal operators not starting with
underscores (which are, strangely, legal) to more explicitly state that such
operators can't be called by literals. Remove the special-case diagnostic for
hexfloats, since it was both triggering in the wrong cases and incorrect.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152287 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
| |
block variable. // rdar://10817031
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152273 91177308-0d34-0410-b5e6-96231b3b80d8
|