On 3/1/24 10:32, Jason Merrill wrote:
On 3/1/24 10:00, Patrick Palka wrote:
On Fri, 1 Mar 2024, Jason Merrill wrote:
On 2/29/24 15:56, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
-- >8 --
For local enums defined in a non-template function or a function
template
instantiation it seems we neglect to make the function depend on the
enum
definition, which ultimately causes streaming to fail due to the enum
definition not being streamed before uses of its enumerators are
streamed,
as far as I can tell.
I would think that the function doesn't need to depend on the local
enum in
order for the local enum to be streamed before the use of the
enumerator,
which comes after the definition of the enum in the function body?
Why isn't streaming the body of the function outputting the enum
definition
before the use of the enumerator?
IIUC (based on observing the behavior for local classes) streaming the
definition of a local class/enum as part of the function definition is
what we want to avoid; we want to treat a local type definition as a
logically separate definition and stream it separately (similar
to class defns vs member defns I guess). And by not registering a
dependency
between the function and the local enum, we end up never streaming out
the local enum definition separately and instead stream it out as part
of the function definition (accidentally) which we then can't stream in
properly.
Perhaps the motivation for treating local type definitions as logically
separate from the function definition is because they can leak out of a
function with a deduced return type:
auto f() {
struct A { };
return A();
}
using type = decltype(f()); // refers directly to f()::A
Yes, I believe that's what modules.cc refers to as a "voldemort".
But for non-voldemort local types, the declaration of the function
doesn't depend on them, only the definition. Why doesn't streaming them
in the definition work properly?
And does your 99426 patch address that problem?
Jason
