| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
| |
user interface and documentation, and update __cplusplus for C++20.
WG21 considers the C++20 standard to be finished (even though it still
has some more steps to pass through in the ISO process).
The old flag names are accepted for compatibility, as usual, and we
still have lots of references to C++2a in comments and identifiers;
those can be cleaned up separately.
(cherry picked from commit 24ad121582454e625bdad125c90d9ac0dae948c8)
|
|
|
|
|
|
|
|
|
| |
list constructor when initializing from {}.
We would previously pick between calling an initializer list constructor
and calling a default constructor unstably in this situation, depending
on whether the inherited default constructor had already been used
elsewhere in the program.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
explicit functions that are not candidates.
It's not always obvious that the reason a conversion was not possible is
because the function you wanted to call is 'explicit', so explicitly say
if that's the case.
It would be nice to rank the explicit candidates higher in the
diagnostic if an implicit conversion sequence exists for their
arguments, but unfortunately we can't determine that without potentially
triggering non-immediate-context errors that we're not permitted to
produce.
|
|
|
|
|
|
| |
This adds some initial syntactic checking that only the appropriate
function signatures can be defaulted. No implicit definitions are
generated yet.
|
|
|
|
|
|
|
|
|
|
|
| |
appropriate during constant evaluation.
Note that the evaluator is sometimes invoked on incomplete expressions.
In such cases, if an object is constructed but we never reach the point
where it would be destroyed (and it has non-trivial destruction), we
treat the expression as having an unmodeled side-effect.
llvm-svn: 372538
|
|
|
|
|
|
|
| |
tuple-like decomposition that produces value-dependent reference
bindings.
llvm-svn: 369829
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Allow implementations to provide complete definitions of
std::tuple_size<T>, but to omit the 'value' member to signal that T is
not tuple-like. The Microsoft standard library implements
std::tuple_size<const T> this way.
If the value member exists, clang still validates that it is an ICE, but
if it does not, then the type is considered to not be tuple-like.
Fixes PR33236
Reviewers: rsmith
Differential Revision: https://reviews.llvm.org/D66040
llvm-svn: 369043
|
|
|
|
|
|
|
|
|
| |
Improved wording and also simplified by using printing
method from qualifiers.
Differential Revision: https://reviews.llvm.org/D62914
llvm-svn: 364023
|
|
|
|
|
|
| |
defaulted special member matches the implicit exception specification.
llvm-svn: 360011
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
render the function deleted instead of rendering the program ill-formed.
This change also adds an enabled-by-default warning for the case where
an explicitly-defaulted special member function of a non-template class
is implicitly deleted by the type checking rules. (This fires either due
to this language change or due to pre-C++20 reasons for the member being
implicitly deleted). I've tested this on a large codebase and found only
bugs (where the program means something that's clearly different from
what the programmer intended), so this is enabled by default, but we
should revisit this if there are problems with this being enabled by
default.
llvm-svn: 343285
|
|
|
|
|
|
| |
members.
llvm-svn: 343036
|
|
|
|
|
|
|
|
| |
rules
Differential revision: https://reviews.llvm.org/D50418
llvm-svn: 339375
|
|
|
|
|
|
| |
only invoke converting constructors of the reference's underlying type.
llvm-svn: 336153
|
|
|
|
|
|
| |
not an aggregtae.
llvm-svn: 334763
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch adds tests of narrowing conversion diagnostics for the
'unscoped enum -> integer' case.
Reviewers: faisalv, rsmith, rogfer01
Reviewed By: rogfer01
Subscribers: cfe-commits, rogfer01
Differential Revision: https://reviews.llvm.org/D43572
llvm-svn: 326551
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
According to [dcl.init.list]p7:
A narrowing conversion is an implicit conversion
- ...
- from an integer type or unscoped enumeration type to a
floating-point type, except where the source is a constant
expression and the actual value after conversion will fit into
the target type and will produce the original value when
converted back to the original type, or
- ...
Currently clang does not handle the 'unscoped enumeration' case. This
patch fixes the corresponding check.
Reviewers: faisalv, rsmith, rogfer01
Reviewed By: rogfer01
Subscribers: rogfer01, cfe-commits
Differential Revision: https://reviews.llvm.org/D42545
llvm-svn: 325668
|
|
|
|
|
|
|
|
|
|
|
| |
an inline namespace, update its semantic DeclContext to match.
We would previously get the semantic DeclContext wrong (pointing to the named
scope rather than the inline namespace within it), resulting in wrong lookup
results and linkage-related problems if the inline namespace was an anonymous
namespace.
llvm-svn: 321770
|
|
|
|
|
|
|
|
| |
This allows you to dump C++ code that spells bool instead of _Bool, leaves off the elaborated type specifiers when printing struct or class names, and other C-isms.
Fixes the -Wreorder issue and fixes the ast-dump-color.cpp test.
llvm-svn: 321310
|
|
|
|
|
|
| |
Misc/ast-dump-color.cpp.
llvm-svn: 321229
|
|
|
|
|
|
| |
This allows you to dump C++ code that spells bool instead of _Bool, leaves off the elaborated type specifiers when printing struct or class names, and other C-isms.
llvm-svn: 321223
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A function declared in a friend declaration may have declarations prior
to the containing class definition. If such declaration defines default
argument, the friend function declaration inherits them. This behavior
causes problems if the class where the friend is declared is a template:
during the class instantiation the friend function looks like if it had
default arguments, so error is triggered.
With this change friend functions declared in class templates do not
inherit default arguments. Actual set of them will be defined at the
point where the containing class is instantiated.
This change fixes PR12724.
Differential Revision: https://reviews.llvm.org/D30393
llvm-svn: 304965
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After r264564, we allowed direct-list-initialization of an enum from an
integral value in C++1z mode, so long as that value can convert to the
enum's underlying type.
In this kind of initialization, we need a lvalue-to-rvalue conversion
for the initializer value if it is not a rvalue. This lets us accept the
following code:
enum class A : unsigned {};
A foo(unsigned x) { return A{x}; }
Differential Revision: https://reviews.llvm.org/D29723
llvm-svn: 295266
|
|
|
|
|
|
| |
constructors to better match the pre-P0136R1 behavior.
llvm-svn: 291955
|
|
|
|
| |
llvm-svn: 289630
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
mirror the description in the standard. Per DR1295, this means that binding a
const / rvalue reference to a bit-field no longer "binds directly", and per
P0135R1, this means that we materialize a temporary in reference binding
after adjusting cv-qualifiers and before performing a derived-to-base cast.
In C++11 onwards, this should have fixed the last case where we would
materialize a temporary of the wrong type (with a subobject adjustment inside
the MaterializeTemporaryExpr instead of outside), but we still have to deal
with that possibility in C++98, unless we want to start using xvalues to
represent materialized temporaries there too.
llvm-svn: 289250
|
|
|
|
|
|
|
|
| |
tuple-like interpretation of decomposition declaration even if there is no
::value member. We already did this, anticipating this resolution, just update
comments and tweak a testcase.
llvm-svn: 289021
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
constructors
Summary:
The C++17 rules for aggregate initialization changed to disallow types with explicit constructors [dcl.init.aggr]p1. This patch implements that new rule.
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D25654
llvm-svn: 288565
|
|
|
|
| |
llvm-svn: 284906
|
|
|
|
|
|
|
| |
implements the bulk of the change (modifying the type system to include
exception specifications), but not all the details just yet.
llvm-svn: 284337
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
copy-initialization. We previously got this wrong in a couple of ways:
- we only looked for copy / move constructors and constructor templates for
this copy, and thus would fail to copy in cases where doing so should use
some other constructor (but see core issue 670),
- we mishandled the special case for disabling user-defined conversions that
blocks infinite recursion through repeated application of a copy constructor
(applying it in slightly too many cases) -- though as far as I can tell,
this does not ever actually affect the result of overload resolution, and
- we misapplied the special-case rules for constructors taking a parameter
whose type is a (reference to) the same class type by incorrectly assuming
that only happens for copy/move constructors (it also happens for
constructors instantiated from templates and those inherited from base
classes).
These changes should only affect strange corner cases (for instance, where the
copy constructor exists but has a non-const-qualified parameter type), so for
the most part it only causes us to produce more 'candidate' notes, but see the
test changes for other cases whose behavior is affected.
llvm-svn: 280776
|
|
|
|
|
|
| |
C++ language standard is not C++98.
llvm-svn: 280309
|
|
|
|
|
|
| |
The diagnostic format was invalid.
llvm-svn: 278487
|
|
|
|
| |
llvm-svn: 278447
|
|
|
|
|
|
|
| |
decomposition declaration for arrays, aggregate-like structs, tuple-like
types, and (as an extension) for complex and vector types.
llvm-svn: 278435
|
|
|
|
|
|
|
| |
Remove the floating point to bool conversion warnings. Some of these
conversions will be caught by -Wliteral-conversion and -Wfloat-conversion
llvm-svn: 267234
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Restructure the implict floating point to integer conversions so that
interesting sub-groups are under different flags. Breakdown of warnings:
No warning:
Exact conversions from floating point to integer:
int x = 10.0;
int x = 1e10;
-Wliteral-conversion - Floating point literal to integer with rounding:
int x = 5.5;
int x = -3.4;
-Wfloat-conversion - All conversions not covered by the above two:
int x = GetFloat();
int x = 5.5 + 3.5;
-Wfloat-zero-conversion - The expression converted has a non-zero floating
point value that gets converted to a zero integer value, excluded the cases
falling under -Wliteral-conversion. Subset of -Wfloat-conversion.
int x = 1.0 / 2.0;
-Wfloat-overflow-conversion - The floating point value is outside the range
of the integer type, exluding cases from -Wliteral conversion. Subset of
-Wfloat-conversion.
char x = 500;
char x = -1000;
-Wfloat-bool-conversion - Any conversion of a floating point type to bool.
Subset of -Wfloat-conversion.
if (GetFloat()) {}
bool x = 5.0;
-Wfloat-bool-constant-conversion - Conversion of a compile time evaluatable
floating point value to bool. Subset of -Wfloat-bool-conversion.
bool x = 1.0;
bool x = 4.0 / 20.0;
Also add EvaluateAsFloat to Sema, which is similar to EvaluateAsInt, but for
floating point values.
llvm-svn: 267054
|
|
|
|
|
|
| |
is fixed
llvm-svn: 264642
|
|
|
|
|
|
| |
value that can convert to the enum's underlying type.
llvm-svn: 264564
|
|
|
|
|
|
| |
classes; these are initialized as if they were data members.
llvm-svn: 262963
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If we import a module that has a complete array type and one that has an
incomplete array type, the declaration found by name lookup might be the one with
the incomplete type, possibly resulting in rejects-valid.
Now, the name lookup prefers decls with a complete array types. Also,
diagnose cases when the redecl chain has array bound, different from the merge
candidate.
Reviewed by Richard Smith.
llvm-svn: 262189
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
C++11 requires const objects to have a user-provided constructor, even for
classes without any fields. DR 253 relaxes this to say "If the implicit default
constructor initializes all subobjects, no initializer should be required."
clang is currently the only compiler that implements this C++11 rule, and e.g.
libstdc++ relies on something like DR 253 to compile in newer versions. This
change makes it possible to build code that says `const vector<int> v;' again
when using libstdc++5.2 and _GLIBCXX_DEBUG
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60284).
Fixes PR23381.
http://reviews.llvm.org/D16552
llvm-svn: 261297
|
|
|
|
|
|
|
| |
Added expected diagnostics new to C++11.
Expanded RUN line to: default, C++98/03 and C++11.
llvm-svn: 253371
|
|
|
|
|
|
|
|
|
|
|
| |
We referred to all declaration in definitions in our diagnostic messages
which is can be inaccurate. Instead, classify the declaration and emit
an appropriate diagnostic for the new declaration and an appropriate
note pointing to the old one.
This fixes PR24116.
llvm-svn: 242190
|
|
|
|
| |
llvm-svn: 237507
|
|
|
|
| |
llvm-svn: 237505
|
|
|
|
|
|
|
|
| |
The error has the form ... 'int' ... 'const int' ... dropped qualifiers. At
first glance, it appears that the const qualifier is added. Reverse the types
so that the second type is less qualified than the first.
llvm-svn: 237482
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
r235046 turned "extern __declspec(selectany) int a;" from a declaration into
a definition to fix PR23242 (required for compatibility with mc.exe output).
However, this broke parsing Windows headers: A d3d11 headers contain something
like
struct SomeStruct {};
extern const __declspec(selectany) SomeStruct some_struct;
This is now a definition, and const objects either need an explicit default
ctor or an initializer so this errors out with
d3d11.h(1065,48) :
error: default initialization of an object of const type
'const CD3D11_DEFAULT' without a user-provided default constructor
(cl.exe just doesn't implement this rule, independent of selectany.)
To work around this, weaken this error into a warning for selectany decls
in microsoft mode, and recover with zero-initialization.
Doing this is a bit hairy since it adds a fixit on an error emitted
by InitializationSequence – this means it needs to build a correct AST, which
in turn means InitializationSequence::Failed() cannot return true when this
fixit is applied. As a workaround, the patch adds a fixit member to
InitializationSequence, and InitializationSequence::Perform() prints the
diagnostic if the fixit member is set right after its call to Diagnose.
That function is usually called when InitializationSequences are used –
InitListChecker::PerformEmptyInit() doesn't call it, but the InitListChecker
case never performs default-initialization, so this is technically OK.
This is the alternative, original fix for PR20208 that got reviewed in the
thread "[patch] Improve diagnostic on default-initializing const variables
(PR20208)". This change basically reverts r213725, adds the original fix for
PR20208, and makes the error a warning in Microsoft mode.
llvm-svn: 235166
|
|
|
|
|
|
|
|
| |
This is ill-formed (and cannot be used anyways).
PR23028.
llvm-svn: 233376
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sema::MergeCXXFunctionDecl: propagate hasUnparsedDefaultArg to new decl.
Parser::HandleMemberFunctionDeclDelays: check hasUnparsedDefaultArg
flag.
Parser::ParseLexedMethodDeclaration: handle inherited unparsed default
arg case.
llvm-svn: 229852
|
|
|
|
|
|
| |
conversion.
llvm-svn: 229792
|