* [Bug c++/45923] constexpr diagnostic w/ non-literal
2010-10-06 23:58 [Bug c++/45923] New: constexpr diagnostic w/ non-literal bkoz at gcc dot gnu.org
@ 2010-10-07 15:35 ` jason at gcc dot gnu.org
2010-10-08 17:12 ` bkoz at redhat dot com
` (13 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: jason at gcc dot gnu.org @ 2010-10-07 15:35 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45923
--- Comment #1 from Jason Merrill <jason at gcc dot gnu.org> 2010-10-07 15:35:45 UTC ---
(In reply to comment #0)
> constexpr-basic.cc:20:33: error: ‘double complex::real() const’ is not a
> constexpr function
>
> NO!
Yes. It is not valid for real() to be constexpr in a non-literal class, so it
is not constexpr.
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug c++/45923] constexpr diagnostic w/ non-literal
2010-10-06 23:58 [Bug c++/45923] New: constexpr diagnostic w/ non-literal bkoz at gcc dot gnu.org
2010-10-07 15:35 ` [Bug c++/45923] " jason at gcc dot gnu.org
@ 2010-10-08 17:12 ` bkoz at redhat dot com
2010-10-08 18:38 ` jason at gcc dot gnu.org
` (12 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: bkoz at redhat dot com @ 2010-10-08 17:12 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45923
--- Comment #2 from Benjamin Kosnik <bkoz at redhat dot com> 2010-10-08 17:12:35 UTC ---
> It is not valid for real() to be constexpr in a non-literal class
This is a helpful diagnostic. The existing one is not.
-benjamin
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug c++/45923] constexpr diagnostic w/ non-literal
2010-10-06 23:58 [Bug c++/45923] New: constexpr diagnostic w/ non-literal bkoz at gcc dot gnu.org
2010-10-07 15:35 ` [Bug c++/45923] " jason at gcc dot gnu.org
2010-10-08 17:12 ` bkoz at redhat dot com
@ 2010-10-08 18:38 ` jason at gcc dot gnu.org
2010-11-03 17:32 ` bkoz at gcc dot gnu.org
` (11 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: jason at gcc dot gnu.org @ 2010-10-08 18:38 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45923
--- Comment #3 from Jason Merrill <jason at gcc dot gnu.org> 2010-10-08 18:37:52 UTC ---
(In reply to comment #2)
> > It is not valid for real() to be constexpr in a non-literal class
>
> This is a helpful diagnostic. The existing one is not.
constexpr-basic.cc:9:20: error: enclosing class of ‘constexpr double
complex::real() const’ is not a literal type
isn't clear enough? How about
"non-static member function %D declared 'constexpr' in non-literal type"
?
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug c++/45923] constexpr diagnostic w/ non-literal
2010-10-06 23:58 [Bug c++/45923] New: constexpr diagnostic w/ non-literal bkoz at gcc dot gnu.org
` (2 preceding siblings ...)
2010-10-08 18:38 ` jason at gcc dot gnu.org
@ 2010-11-03 17:32 ` bkoz at gcc dot gnu.org
2010-11-03 17:37 ` bkoz at gcc dot gnu.org
` (10 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: bkoz at gcc dot gnu.org @ 2010-11-03 17:32 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45923
--- Comment #4 from Benjamin Kosnik <bkoz at gcc dot gnu.org> 2010-11-03 17:32:23 UTC ---
This is going to be re-purposed into a more general bugreport about constexpr
and diagnostics. The goal is to try and get compiler messages about why code
constructs are or are not valid constant expressions that contain:
1) locality as to where the problem is
2) clarity as to what the problem is
3) notes as to potential fixes.
Now, on to the attachments.
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug c++/45923] constexpr diagnostic w/ non-literal
2010-10-06 23:58 [Bug c++/45923] New: constexpr diagnostic w/ non-literal bkoz at gcc dot gnu.org
` (3 preceding siblings ...)
2010-11-03 17:32 ` bkoz at gcc dot gnu.org
@ 2010-11-03 17:37 ` bkoz at gcc dot gnu.org
2010-11-03 17:42 ` bkoz at gcc dot gnu.org
` (9 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: bkoz at gcc dot gnu.org @ 2010-11-03 17:37 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45923
--- Comment #5 from Benjamin Kosnik <bkoz at gcc dot gnu.org> 2010-11-03 17:37:39 UTC ---
Created attachment 22256
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22256
constexpr diagnostics test case #01
This is a test case that shows locality information for failed constant
expressions in a simple class hierarchy.
The test case is comprised of a base class with member data, and no constexpr
constructor.
The error is:
%$bin/H-x86_64-gcc-trunk.20101101/bin/g++ -g -std=gnu++0x
constexpr-diagnostics-base1.cc
constexpr-diagnostics-base1.cc:18:19: error: the type ‘const derived’ of
constexpr variable ‘obj’ is not literal
The error desired is:
%$bin/H-x86_64-gcc-trunk.20101101/bin/g++ -g -std=gnu++0x
constexpr-diagnostics-base1.cc
constexpr-diagnostics-base1.cc:18:19: error: the type ‘const derived’ of
constexpr variable ‘obj’ is not literal
constexpr-diagnostics-base1.cc:8: error: base class constructor is not
"constexpr"
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug c++/45923] constexpr diagnostic w/ non-literal
2010-10-06 23:58 [Bug c++/45923] New: constexpr diagnostic w/ non-literal bkoz at gcc dot gnu.org
` (4 preceding siblings ...)
2010-11-03 17:37 ` bkoz at gcc dot gnu.org
@ 2010-11-03 17:42 ` bkoz at gcc dot gnu.org
2010-11-03 20:48 ` bkoz at gcc dot gnu.org
` (8 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: bkoz at gcc dot gnu.org @ 2010-11-03 17:42 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45923
--- Comment #6 from Benjamin Kosnik <bkoz at gcc dot gnu.org> 2010-11-03 17:42:08 UTC ---
Created attachment 22257
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22257
constexpr diagnostics test case #02
This diagnostic is for defaulted constructors. At this point, g++ is going a
pretty good job on this diagnostic. This testcase just marks the effort needed
to get to this point so that in the future there are no regressions.
struct base
{
int _M_i;
constexpr base() = default;
};
constexpr base obj;
gives:
%$bin/H-x86_64-gcc-trunk.20101101/bin/g++ -g -std=gnu++0x
constexpr-diagnostics-defaulted.cc
constexpr-diagnostics-defaulted.cc:2:8: error: ‘constexpr base::base()’ cannot
be declared as constexpr
constexpr-diagnostics-defaulted.cc:9:16: error: uninitialized const ‘obj’
[-fpermissive]
constexpr-diagnostics-defaulted.cc:2:8: note: ‘const struct base’ has no
user-provided default constructor
constexpr-diagnostics-defaulted.cc:6:13: note: constructor is not user-provided
because it is explicitly defaulted in the class body
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug c++/45923] constexpr diagnostic w/ non-literal
2010-10-06 23:58 [Bug c++/45923] New: constexpr diagnostic w/ non-literal bkoz at gcc dot gnu.org
` (5 preceding siblings ...)
2010-11-03 17:42 ` bkoz at gcc dot gnu.org
@ 2010-11-03 20:48 ` bkoz at gcc dot gnu.org
2010-11-03 20:55 ` bkoz at gcc dot gnu.org
` (7 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: bkoz at gcc dot gnu.org @ 2010-11-03 20:48 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45923
--- Comment #7 from Benjamin Kosnik <bkoz at gcc dot gnu.org> 2010-11-03 20:48:38 UTC ---
Created attachment 22266
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22266
constexpr diagnostics test case #03
more locality, from this under-development chrono snippet.
%$bin/H-x86_64-gcc-trunk/bin/g++ -c -std=gnu++0x
constexpr-diagnostics-location1.cc
constexpr-diagnostics-location1.cc: In function ‘void test1()’:
constexpr-diagnostics-location1.cc:720:32: error: ‘constexpr
std::chrono::duration<_Rep, _Period>::duration(const
std::chrono::duration<_Rep2, _Period2>&) [with _Rep2 = int, _Period2 =
std::ratio<3600l>, <template-parameter-2-3> = void, _Rep = long int, _Period =
std::ratio<1l>]’ is not a constexpr function
But what we really want is added note
constexpr-diagnostics-location1.cc:155: note: calls non-constexpr function
'duration_cast'
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug c++/45923] constexpr diagnostic w/ non-literal
2010-10-06 23:58 [Bug c++/45923] New: constexpr diagnostic w/ non-literal bkoz at gcc dot gnu.org
` (6 preceding siblings ...)
2010-11-03 20:48 ` bkoz at gcc dot gnu.org
@ 2010-11-03 20:55 ` bkoz at gcc dot gnu.org
2010-11-11 4:54 ` [Bug c++/45923] constexpr diagnostics, more more bkoz at gcc dot gnu.org
` (6 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: bkoz at gcc dot gnu.org @ 2010-11-03 20:55 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45923
--- Comment #8 from Benjamin Kosnik <bkoz at gcc dot gnu.org> 2010-11-03 20:55:42 UTC ---
Created attachment 22268
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22268
constexpr diagnostics test case #04
This is just a test case for previously-reported-and fixed bug. Let's keep it
around to avoid regressions.
%$bin/H-x86_64-gcc-trunk/bin/g++ -c -std=gnu++0x
constexpr-diagnostics-initalizer1.cc
constexpr-diagnostics-initalizer1.cc: In function ‘int main()’:
constexpr-diagnostics-initalizer1.cc:21:21: in constexpr expansion of ‘A((* &
a1))’
constexpr-diagnostics-initalizer1.cc:21:21: error: the value of ‘a1’ is not
usable in a constant expression
constexpr-diagnostics-initalizer1.cc:20:13: note: ‘a1’ was not declared
‘constexpr’
What we really need is the last line, the note: 'a1' was not declared constexpr
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug c++/45923] constexpr diagnostics, more more
2010-10-06 23:58 [Bug c++/45923] New: constexpr diagnostic w/ non-literal bkoz at gcc dot gnu.org
` (7 preceding siblings ...)
2010-11-03 20:55 ` bkoz at gcc dot gnu.org
@ 2010-11-11 4:54 ` bkoz at gcc dot gnu.org
2010-11-24 21:00 ` bkoz at gcc dot gnu.org
` (5 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: bkoz at gcc dot gnu.org @ 2010-11-11 4:54 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45923
--- Comment #9 from Benjamin Kosnik <bkoz at gcc dot gnu.org> 2010-11-11 04:54:49 UTC ---
Oh, i thought of another thing, if non-literal type with a constexpr
constructor is used to define a namespace-scope static variable, and the
"constexpr" creation cannot be honored, then we should get a helpful note that
warns the user that it failed and to anticipate possible dynamic
initialization.
I don't believe a diagnostic is required in this case but an optional warning
might be useful.
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug c++/45923] constexpr diagnostics, more more
2010-10-06 23:58 [Bug c++/45923] New: constexpr diagnostic w/ non-literal bkoz at gcc dot gnu.org
` (8 preceding siblings ...)
2010-11-11 4:54 ` [Bug c++/45923] constexpr diagnostics, more more bkoz at gcc dot gnu.org
@ 2010-11-24 21:00 ` bkoz at gcc dot gnu.org
2011-01-20 20:00 ` bkoz at gcc dot gnu.org
` (4 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: bkoz at gcc dot gnu.org @ 2010-11-24 21:00 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45923
--- Comment #10 from Benjamin Kosnik <bkoz at gcc dot gnu.org> 2010-11-24 20:44:49 UTC ---
Follow up to #9, as per discussions in Batavia and
http://gcc.gnu.org/ml/gcc-patches/2010-11/msg02406.html
There was some thought of providing an attribute syntax for this, say something
like __attribute__((init_constant)) that would warn when the variable
wasn't constant initialized. Spelling to be determined....
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug c++/45923] constexpr diagnostics, more more
2010-10-06 23:58 [Bug c++/45923] New: constexpr diagnostic w/ non-literal bkoz at gcc dot gnu.org
` (9 preceding siblings ...)
2010-11-24 21:00 ` bkoz at gcc dot gnu.org
@ 2011-01-20 20:00 ` bkoz at gcc dot gnu.org
2011-06-27 4:10 ` jason at gcc dot gnu.org
` (3 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: bkoz at gcc dot gnu.org @ 2011-01-20 20:00 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45923
--- Comment #11 from Benjamin Kosnik <bkoz at gcc dot gnu.org> 2011-01-20 19:27:27 UTC ---
Know this is not high-priority bug for 4.6.0 but it should be as constexpr is a
new feature and the initial QoI for diagnostics is important for user's first
impressions. Diagnostics are lagging, as this is a new form of C++ diagnostic:
there are some interesting opportunities here. We can do better!!
I've given some examples, but I'm not quite sure what is required and what
Jason and Gaby are thinking in terms of how this stuff should be architected.
Thoughts or sketches guys?
If a plan can be outlined here in bugzilla, then perhaps it could be split into
smaller parts and independently executed?
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug c++/45923] constexpr diagnostics, more more
2010-10-06 23:58 [Bug c++/45923] New: constexpr diagnostic w/ non-literal bkoz at gcc dot gnu.org
` (10 preceding siblings ...)
2011-01-20 20:00 ` bkoz at gcc dot gnu.org
@ 2011-06-27 4:10 ` jason at gcc dot gnu.org
2011-06-29 14:36 ` jason at gcc dot gnu.org
` (2 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: jason at gcc dot gnu.org @ 2011-06-27 4:10 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45923
Jason Merrill <jason at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed| |2011.06.27 04:09:51
AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug c++/45923] constexpr diagnostics, more more
2010-10-06 23:58 [Bug c++/45923] New: constexpr diagnostic w/ non-literal bkoz at gcc dot gnu.org
` (11 preceding siblings ...)
2011-06-27 4:10 ` jason at gcc dot gnu.org
@ 2011-06-29 14:36 ` jason at gcc dot gnu.org
2011-07-05 3:53 ` b.r.longbons at gmail dot com
2011-07-25 23:59 ` jason at gcc dot gnu.org
14 siblings, 0 replies; 16+ messages in thread
From: jason at gcc dot gnu.org @ 2011-06-29 14:36 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45923
--- Comment #12 from Jason Merrill <jason at gcc dot gnu.org> 2011-06-29 14:35:03 UTC ---
Author: jason
Date: Wed Jun 29 14:34:58 2011
New Revision: 175646
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175646
Log:
PR c++/45923
* class.c (explain_non_literal_class): New.
(finalize_literal_type_property): Call it.
* cp-tree.h: Declare it.
* semantics.c (ensure_literal_type_for_constexpr_object): Call it.
(is_valid_constexpr_fn): Likewise.
(massage_constexpr_body): Split out from...
(register_constexpr_fundef): ...here.
(is_instantiation_of_constexpr): New.
(expand_or_defer_fn_1): Leave DECL_SAVED_TREE alone in that case.
(explain_invalid_constexpr_fn): New.
(cxx_eval_call_expression): Call it.
(potential_constant_expression_1): Likewise. Avoid redundant errors.
* method.c (process_subob_fn): Diagnose non-constexpr.
(walk_field_subobs): Likewise.
(synthesized_method_walk): Don't shortcut if we want diagnostics.
(explain_implicit_non_constexpr): New.
(defaulted_late_check): Use it.
* call.c (build_cxx_call): Remember location.
Added:
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-diag3.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/cp/class.c
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/method.c
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-diag1.C
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-ex1.C
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-friend.C
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-incomplete2.C
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug c++/45923] constexpr diagnostics, more more
2010-10-06 23:58 [Bug c++/45923] New: constexpr diagnostic w/ non-literal bkoz at gcc dot gnu.org
` (12 preceding siblings ...)
2011-06-29 14:36 ` jason at gcc dot gnu.org
@ 2011-07-05 3:53 ` b.r.longbons at gmail dot com
2011-07-25 23:59 ` jason at gcc dot gnu.org
14 siblings, 0 replies; 16+ messages in thread
From: b.r.longbons at gmail dot com @ 2011-07-05 3:53 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45923
Ben Longbons <b.r.longbons at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |b.r.longbons at gmail dot
| |com
--- Comment #13 from Ben Longbons <b.r.longbons at gmail dot com> 2011-07-05 03:52:15 UTC ---
Also it seems the destructor must be defaulted. I thought (incorrectly) that
only constructors mattered, so tried:
protected:
~Base() {}
which yields for members:
error: enclosing class of '...' is not a literal type
and for nonmembers:
error: invalid return type 'Derived' of constexpr function '...'
but this works:
protected:
~Base() = default;
specifically, a 'literal type' requires literal members and bases and:
* a trivial default constructor or at least one constexpr constructor besides
the copy/move constructors (3.9 #10).
* a trivial destructor: non-virtual, non-deleted, non-user-provided (12.4 #3)
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug c++/45923] constexpr diagnostics, more more
2010-10-06 23:58 [Bug c++/45923] New: constexpr diagnostic w/ non-literal bkoz at gcc dot gnu.org
` (13 preceding siblings ...)
2011-07-05 3:53 ` b.r.longbons at gmail dot com
@ 2011-07-25 23:59 ` jason at gcc dot gnu.org
14 siblings, 0 replies; 16+ messages in thread
From: jason at gcc dot gnu.org @ 2011-07-25 23:59 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45923
Jason Merrill <jason at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |FIXED
Target Milestone|--- |4.7.0
--- Comment #14 from Jason Merrill <jason at gcc dot gnu.org> 2011-07-25 23:58:52 UTC ---
I believe this is now fixed.
^ permalink raw reply [flat|nested] 16+ messages in thread