This is an archive of the discontinued LLVM Phabricator instance.

[clang][NFC] rename getOwningModuleForLinkage to getModuleAttachment
Needs ReviewPublic

Authored by urnathan on Feb 15 2022, 5:06 AM.

Details

Summary

The name 'getOwningModuleForLinkage' is a little confusing, now that the standard defines the term 'attachment' to mean the same thing. Renames the function to match the latter.

Note, the ModuleInternalLinkage concept will go away (and hence the defaulted argument) once p1815 is implemented. This is already noted in the body of the function.

This is based on top of the new mangling patch, but I could rebase it before if that's prefered.

Diff Detail

Event Timeline

urnathan requested review of this revision.Feb 15 2022, 5:06 AM
urnathan created this revision.

The new name is confusing to me. According to my understanding, Decl::getOwningModule() already defines the semantic of attached module. And for the new name, here is an example:

C++
module;
void foo() { ... }
export module m;
...

Now the getOwningModuleForLinkage would return nullptr for foo since it lives in global module fragment and it is external so we decide to not break its ABI. But it is attached to global module fragment indeed. So I might be surprising if found Decl::getModuleAttachment return nullptr for the similar example above.

The new name is confusing to me. According to my understanding, Decl::getOwningModule() already defines the semantic of attached module. And for the new name, here is an example:

C++
module;
void foo() { ... }
export module m;
...

Now the getOwningModuleForLinkage would return nullptr for foo since it lives in global module fragment and it is external so we decide to not break its ABI. But it is attached to global module fragment indeed. So I might be surprising if found Decl::getModuleAttachment return nullptr for the similar example above.

Hm, what about:

C++
export module Foo;
extern "C++" { export void Baz (); }

Baz is visible by name to importers of Foo, but it is attached to the global module. Is it owned by Foo or a global module fragment? If the former, then getOwningModule is not telling you about attachment.

The new name is confusing to me. According to my understanding, Decl::getOwningModule() already defines the semantic of attached module. And for the new name, here is an example:

C++
module;
void foo() { ... }
export module m;
...

Now the getOwningModuleForLinkage would return nullptr for foo since it lives in global module fragment and it is external so we decide to not break its ABI. But it is attached to global module fragment indeed. So I might be surprising if found Decl::getModuleAttachment return nullptr for the similar example above.

Hm, what about:

C++
export module Foo;
extern "C++" { export void Baz (); }

Baz is visible by name to importers of Foo, but it is attached to the global module. Is it owned by Foo or a global module fragment? If the former, then getOwningModule is not telling you about attachment.

It is owned by global module fragment. I am sure about this.

Could we abandon this one?

Herald added a project: Restricted Project. · View Herald TranscriptMar 3 2022, 6:40 PM