This is an archive of the discontinued LLVM Phabricator instance.

[C++20][Modules] Correct an assert for modules-ts.
ClosedPublic

Authored by iains on Mar 24 2022, 6:12 AM.

Details

Summary

When adding the support for modules partitions we added an assert that the
actual status of Global Module Fragments matches the state machine that is
driven by the module; keyword.

That does not apply to the modules-ts case, where there is an implicit GMF.

Diff Detail

Event Timeline

iains created this revision.Mar 24 2022, 6:12 AM
Herald added a project: Restricted Project. · View Herald TranscriptMar 24 2022, 6:12 AM
iains published this revision for review.Mar 24 2022, 6:13 AM
iains added a reviewer: urnathan.

somewhat on the trivial side.

Herald added a project: Restricted Project. · View Herald TranscriptMar 24 2022, 6:15 AM
Herald added a subscriber: cfe-commits. · View Herald Transcript

Is this because of history that ModulesTS option != p1103 modules? I thought we wanted to make the former become the latter (i.e. ModuleTS is the same as CPlusPlusModules) This seems to be moving in the wrong direction.

iains added a comment.Mar 24 2022, 7:05 AM

Is this because of history that ModulesTS option != p1103 modules? I thought we wanted to make the former become the latter (i.e. ModuleTS is the same as CPlusPlusModules) This seems to be moving in the wrong direction.

This is because we are not removing the fmodules-ts flag (nor. at this point, the code that it changes) - as I understand things. So I have now to fix (next patch) the problem that we currently generate wrong code for static vars and lambdas in modules since the linkage is defaulting to the modules-ts "module internal" model.

So, unless we shift priorities such that we take a detour to remove the modules-ts support, I need to make this change to avoid the assert firing for -fmodules-ts (it seems we have limited testing - since nothing fired until I tried to make other changes form my patchset).

urnathan accepted this revision.Mar 25 2022, 3:56 AM

Understood. To document the approach:

  1. clearly separate -fmodules-ts semantics (which are vague in places, but whatever)
  2. implement c++20 modules semantics

3a) switch -fmodules-ts option to behave as #2 and delete any now-unreachable TS-specific code
3b) deprecate -fmodules-ts option and then remove.

This revision is now accepted and ready to land.Mar 25 2022, 3:56 AM
This revision was automatically updated to reflect the committed changes.