>
> Do you object to anything I proposed other than removing the
> representation of the anonymous class compilers generate for lambdas?
>
I'm not a /super/ fan of introducing a bunch of locals in addition to the
member descriptions - it'll be a bunch of extra DWARF that'd be nice to
avoid if we can...
But putting object_pointer on the class member that stores "this" seems
problematic since that's effectively at the same scope as the real object
pointer - it'd be awkward to say there's two "this" at the same scope and
have to say that the member variable "this" shadows the real "this" in some
way.
And then you want the captured variables to be in a scope that is inside
the "this" scope so they override unqualified lookup for any names that are
also members of "this"...
So, yeah, I get why you/gcc developers arrived where they did. I wouldn't
mind some size analysis to see how bad the regression/cost is, that might
help inform whether it's worth trying to address it.
> Because that's not really essential to what I want to do if we're fine
> with DW_AT_object_pointer pointing to a variable that doesn't share a
> containing type.
>
Yeah, this general idea I think I'm down with - if it generalizes to
scope-based "this" in other languages/features, etc, that seems good.
>
> Now that I've thought about it a bit more I think that is not
> particularly weird. Rust for example allows
>
> fn member(self: Rc<Self>, arg1: Foo, ...)
>
> where the type of the receiver can be certain things that are
> convertible to the containing object but are definitely not the
> containing object. rustc doesn't emit DW_AT_object_pointer today but
> it should.
>
> - Kyle
>
>
> > Introducing a bunch of locals that expose the right names/types - seems
> OK to me.
> >
> > Using object_pointer to refer to a local "this" could have other uses
> too - some languages (I forget which ones) have a scope based object usage,
> like "foo f; f.x();" -> "using (foo f) { x(); }" and so using
> object_pointer on the scope to refer to the local could be used to support
> that feature.
>
> - Kyle
>
--
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
