This revision was automatically updated to reflect the committed changes.
Closed by commit rL312007: [modules-ts] Omit submodule semantics for TS modules
(authored by borisk).
Changed prior to commit:
https://reviews.llvm.org/D35678?vs=110875&id=113098#toc
Repository:
rL LLVM
https://review
boris added a comment.
In https://reviews.llvm.org/D35678#842891, @rsmith wrote:
> I'd still like the id flattening moved to the caller. [...] I'm fine with
> that being done as a separate change after this one, though, if you'd prefer.
Yes, that would probably be easier.
> Do you need someon
rsmith accepted this revision.
rsmith added a comment.
This revision is now accepted and ready to land.
In https://reviews.llvm.org/D35678#840092, @boris wrote:
> My understanding of your comment is that the rest is ok for now (since there
> will probably be a redesign in this area). If, however
boris updated this revision to Diff 110875.
boris added a comment.
Richard, sorry for the last ping, somehow I missed your review.
I've uploaded a new revision with a test case (note that the issue is with
'module a.b' not 'import a.b' but I have tested both for good measure).
My understanding
boris added a comment.
Ping.
https://reviews.llvm.org/D35678
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
rsmith added a comment.
This will need a test case.
Comment at: lib/Frontend/CompilerInstance.cpp:1598-1612
+ // FIXME: Should we be deciding whether this is a submodule (here and
+ // below) based on -fmodules-ts or should we pass a flag and make the
+ // caller decide?
+
boris added a comment.
Ping.
https://reviews.llvm.org/D35678
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
boris added a comment.
Ping.
https://reviews.llvm.org/D35678
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
boris created this revision.
If a TS module name has more than one component (e.g., foo.bar) then we
erroneously activate the submodule semantics when encountering a module
declaration in the module implementation unit (e.g., module foo.bar;).
https://reviews.llvm.org/D35678
Files:
lib/Fron
