On 11/1/19 5:19 PM, Jakub Jelinek wrote:
On Fri, Nov 01, 2019 at 09:56:44PM +0100, Jakub Jelinek wrote:
Ah, used 8.x to test it. There have been r265787 and r269775 changes in
between.
Though
auto d = [] () mutable __attribute__((noreturn)) constexpr {};
auto e = [] () mutable
On Fri, Nov 01, 2019 at 09:56:44PM +0100, Jakub Jelinek wrote:
> Ah, used 8.x to test it. There have been r265787 and r269775 changes in
> between.
> Though
> auto d = [] () mutable __attribute__((noreturn)) constexpr {};
> auto e = [] () mutable [[noreturn]] constexpr {};
> is still
On Fri, Nov 01, 2019 at 04:42:45PM -0400, Jason Merrill wrote:
> It isn't accepted for me:
>
> wa3.C: In function 'void foo()':
> wa3.C:4:29: warning: attribute ignored [-Wattributes]
> 4 | auto a = [] () [[noreturn]] constexpr {};
> | ^
> wa3.C:4:29: note:
On 11/1/19 3:57 PM, Jakub Jelinek wrote:
On Fri, Nov 01, 2019 at 03:42:58PM -0400, Jason Merrill wrote:
+ for (size_t n = cp_parser_skip_balanced_tokens (parser, 1); ; n++)
+ {
+ size_t after = cp_parser_skip_attributes_opt (parser, n);
+ if (after > n)
On Fri, Nov 01, 2019 at 03:42:58PM -0400, Jason Merrill wrote:
> > + for (size_t n = cp_parser_skip_balanced_tokens (parser, 1); ; n++)
> > + {
> > + size_t after = cp_parser_skip_attributes_opt (parser, n);
> > + if (after > n)
> > + {
> > + n =
On 10/31/19 1:21 PM, Jakub Jelinek wrote:
On Wed, Oct 30, 2019 at 05:06:00PM -0400, Jason Merrill wrote:
build_cplus_new does the magic of replacing a dummy argument, e.g.
if (obj_arg && is_dummy_object (obj_arg))
{
call = build_cplus_new (DECL_CONTEXT
On 10/24/19 7:47 AM, Jakub Jelinek wrote:
On Tue, Oct 22, 2019 at 10:57:42AM -0400, Jason Merrill wrote:
So, do you prefer to do it the other way during build_cxx_call?
It seems more straightforward.
I've tried this approach, but am running into issues:
1) the normal constructors aren't an
On Tue, Oct 22, 2019 at 10:57:42AM -0400, Jason Merrill wrote:
> > So, do you prefer to do it the other way during build_cxx_call?
>
> It seems more straightforward.
I've tried this approach, but am running into issues:
1) the normal constructors aren't an issue, all I was missing is passing
On Tue, Oct 22, 2019 at 11:20 AM Jakub Jelinek wrote:
>
> On Tue, Oct 22, 2019 at 10:57:42AM -0400, Jason Merrill wrote:
> > > So, do you prefer to do it the other way during build_cxx_call?
> >
> > It seems more straightforward.
>
> Ok.
>
> > > The issues that need to be resolved are the default
On Tue, Oct 22, 2019 at 10:57:42AM -0400, Jason Merrill wrote:
> > So, do you prefer to do it the other way during build_cxx_call?
>
> It seems more straightforward.
Ok.
> > The issues that need to be resolved are the default arguments,
> > which from my understanding are not full expressions
On Tue, Oct 22, 2019 at 10:41 AM Jakub Jelinek wrote:
>
> On Tue, Oct 22, 2019 at 09:55:06AM -0400, Jason Merrill wrote:
> > On Mon, Oct 21, 2019 at 1:59 PM Jason Merrill wrote:
> > > On 10/15/19 1:04 PM, Jakub Jelinek wrote:
> >
> > > > Unlike the previous implementation, this doesn't invoke
On Tue, Oct 22, 2019 at 09:55:06AM -0400, Jason Merrill wrote:
> On Mon, Oct 21, 2019 at 1:59 PM Jason Merrill wrote:
> > On 10/15/19 1:04 PM, Jakub Jelinek wrote:
>
> > > Unlike the previous implementation, this doesn't invoke consteval function
> > > already during parsing, but later on, so
On Tue, Oct 22, 2019 at 09:52:44AM -0400, Jason Merrill wrote:
> Sounds good.
>
> > (the latter perhaps just if !processing_template_decl)?
>
> I'd think we would want to be consistent with other immediate
> invocations in template context.
The other ones just call it regardless of
On Mon, Oct 21, 2019 at 1:59 PM Jason Merrill wrote:
> On 10/15/19 1:04 PM, Jakub Jelinek wrote:
> > Unlike the previous implementation, this doesn't invoke consteval function
> > already during parsing, but later on, so there aren't issues with say
> > consteval constructors or consteval in
On Tue, Oct 22, 2019 at 3:15 AM Jakub Jelinek wrote:
>
> On Mon, Oct 21, 2019 at 04:44:22PM -0400, Jason Merrill wrote:
> > Perhaps we should bypass the existing virtual function call mechanism for
> > consteval, and instead find the complete object directly and call
> > non-virtually.
>
> Maybe,
On Mon, Oct 21, 2019 at 04:44:22PM -0400, Jason Merrill wrote:
> Perhaps we should bypass the existing virtual function call mechanism for
> consteval, and instead find the complete object directly and call
> non-virtually.
Maybe, but can that be done incrementally?
> > The finish_function was
On 10/21/19 2:49 PM, Jakub Jelinek wrote:
On Mon, Oct 21, 2019 at 01:59:38PM -0400, Jason Merrill wrote:
I agree that cp_fold isn't the right place, since it does lowering for GCC
internals, and consteval expansion is part of the language semantics. So it
should happen before constexpr body
On Mon, Oct 21, 2019 at 01:59:38PM -0400, Jason Merrill wrote:
> I agree that cp_fold isn't the right place, since it does lowering for GCC
> internals, and consteval expansion is part of the language semantics. So it
> should happen before constexpr body saving, as in your patch.
>
> It seems
On 10/15/19 1:04 PM, Jakub Jelinek wrote:
Hi!
The following patch implements P1073R3, i.e. consteval, except that
virtual consteval is not supported (I think support for that would need to
include the consteval virtual methods at the end of the binfo structures
after all non-consteval virtual
19 matches
Mail list logo
