On 11/26/23 20:44, waffl3x wrote:
The other problem I'm having is
auto f0 = [n = 5, ](this auto const&){ n = 10; };
This errors just fine, the lambda is unconditionally const so
LAMBDA_EXPR_MUTABLE_P flag is set for the closure.
This on the other hand does not. The constness of the captures
> > > > OKAY, I figured out SOMETHING, I think this should be fine. As noted in
> > > > the comments, this might be a better way of handling the static lambda
> > > > case too. This is still a nasty hack so it should probably be done
> > > > differently, but I question if making a whole new fntype
> > Now with that out of the way, I do still kind of feel icky about it.
> > This really is a MASSIVE edge case that will almost never matter. As
> > far as I know, instantiating explicitly like so...
> >
> > auto f = [x = 42](this auto&&) -> int { return x; };
> > int (*fp)(int&) =
On 11/26/23 18:10, waffl3x wrote:
On Sunday, November 26th, 2023 at 2:30 PM, Jason Merrill
wrote:
On 11/24/23 20:14, waffl3x wrote:
OKAY, I figured out SOMETHING, I think this should be fine. As noted in
the comments, this might be a better way of handling the static lambda
case too. This
On Sunday, November 26th, 2023 at 2:30 PM, Jason Merrill
wrote:
>
>
> On 11/24/23 20:14, waffl3x wrote:
>
> > OKAY, I figured out SOMETHING, I think this should be fine. As noted in
> > the comments, this might be a better way of handling the static lambda
> > case too. This is still
On 11/24/23 20:14, waffl3x wrote:
OKAY, I figured out SOMETHING, I think this should be fine. As noted in
the comments, this might be a better way of handling the static lambda
case too. This is still a nasty hack so it should probably be done
differently, but I question if making a whole new
I don't think so, I'm concerned that it might eat the xobj parameter if
we do it that way. Besides, all we want is the lambda type anyway, I
don't want to build a whole new node just to do that. Upon further
consideration I think my solution does work and shouldn't cause
problems. The field that
On 11/24/23 01:49, waffl3x wrote:
and this in tsubst_lambda_expr that assumes iobj:
/* Fix the type of 'this'. */
fntype = build_memfn_type (fntype, type,
type_memfn_quals (fntype),
type_memfn_rqual (fntype));
Unfortunately, putting a condition on this had some unforeseen
consequences. I've
OKAY, I figured out SOMETHING, I think this should be fine. As noted in
the comments, this might be a better way of handling the static lambda
case too. This is still a nasty hack so it should probably be done
differently, but I question if making a whole new fntype node in
tsubst_lambda_expr
Okay within about half an hour today I think I've figured out what the
main issue is for my problem. For the static lambda case, while I don't
like the hack that's currently present, I reckon we just leave it as it
is, as it works just fine right now. For my issue, I'm not totally sure
how to
> and this in tsubst_lambda_expr that assumes iobj:
>
> /* Fix the type of 'this'. */
> fntype = build_memfn_type (fntype, type,
> type_memfn_quals (fntype),
> type_memfn_rqual (fntype));
Unfortunately, putting a condition on this had some unforeseen
consequences. I've been working on this about
On 11/22/23 15:46, waffl3x wrote:
On Tuesday, November 21st, 2023 at 8:22 PM, Jason Merrill
wrote:
On 11/21/23 08:04, waffl3x wrote:
/* Nonzero for FUNCTION_DECL means that this decl is a non-static
- member function. */
+ member function, use DECL_IOBJ_MEMBER_FUNC_P instead. */
#define
On Wednesday, November 22nd, 2023 at 2:38 PM, Jason Merrill
wrote:
>
>
> On 11/22/23 15:46, waffl3x wrote:
>
> > On Tuesday, November 21st, 2023 at 8:22 PM, Jason Merrill ja...@redhat.com
> > wrote:
> >
> > > On 11/21/23 08:04, waffl3x wrote:
> > >
> > > > /* Nonzero for
On Tuesday, November 21st, 2023 at 8:22 PM, Jason Merrill
wrote:
>
>
> On 11/21/23 08:04, waffl3x wrote:
>
> > Bootstrapped and tested on x86_64-linux with no regressions.
> >
> > Hopefully this patch is legible enough for reviewing purposes, I've not
> > been feeling the greatest so it
> > > > /* Nonzero for FUNCTION_DECL means that this decl is a non-static
> > > > - member function. */
> > > > + member function, use DECL_IOBJ_MEMBER_FUNC_P instead. */
> > > > #define DECL_NONSTATIC_MEMBER_FUNCTION_P(NODE) \
> > > > (TREE_CODE (TREE_TYPE (NODE)) == METHOD_TYPE)
> > > >
> > > >
On 11/21/23 08:04, waffl3x wrote:
Bootstrapped and tested on x86_64-linux with no regressions.
Hopefully this patch is legible enough for reviewing purposes, I've not
been feeling the greatest so it was a task to get this finished.
Tomorrow I will look at putting the diagnostics in
16 matches
Mail list logo
