User Details
- User Since
- Sep 16 2014, 4:54 AM (437 w, 6 d)
Thu, Feb 2
Tue, Jan 31
rebased, added tests for instantiated variable/function templates.
Mon, Jan 30
I think we need to find a way to proceed - because this causes a regression on the llvm-16 branch, and that should be resolved soon, if possible.
What is your suggestion for a way forward?
I think we need to find a way to proceed - because this causes a regression on the llvm-16 branch, and that should be resolved soon, if possible.
What is your suggestion for a way forward?
Sun, Jan 29
AFAICT the failing test is unrelated to this patch.
Sat, Jan 28
in my local testing, I was able to consume all libc++ headers individually.
rebased, and revised to handle variable templates and instantiations.
Fri, Jan 27
this is necessary, but not sufficient (I need to make additions) .. no need to review yet.
@dblaikie - I suspect that this would be useful on the llvm-16 release branch, and so I've added you as a reviewer, if you have some chance to look ..
(I do not think @ChuanqiXu is available until February).
Sun, Jan 22
Sat, Jan 21
Wed, Jan 18
rebased.
rebased
address review commments, add an assert and a FIXME.
rebased, address review comments
Tue, Jan 17
thanks, LGTM.
Mon, Jan 16
well, we anticipated that this could cause some code to flag an error.
Sun, Jan 8
Jan 5 2023
Jan 4 2023
OK. So I've been thinking about this some more and ISTM that if the external source represents a Header Unit, then that has no stand-alone object or initialiser.
how does that look?
rebase, added release notes
Jan 3 2023
your test case only covers itanium ABI - does the process still work properly for non-itanium ABIs?
.. if I remember correctly, the ctor/dtors are all run from the top level module (i.e. it pulls in the imported ones and constructs a composite ctor),
Dec 19 2022
OK so this is what I plan to land assuming testing goes OK.
I suspect that this might cause some user code to flag errors - there are quite a number of ODR violations "in the wild".
rebased, addressed comments.
Dec 18 2022
Dec 17 2022
rebased, amended a comment as suggested
this came up during discussion of other header unit constraints, we had not implemented it yet.
found a test case where we'd accidentally broken this rule too.
Dec 9 2022
this LGTM ( but please wait for an ack from @dblaikie ) and again thanks for patience in seeing this through.
thanks all for the patience on this one - and for the collaborative discussion - I do think the outcome is going to be an easier to remember option name ;)
Dec 5 2022
Nov 8 2022
I think that (if this change is approved) there will be also some simplifications possible in the driver (since the mode that produces a wrapper header for multiple command-line headers is different from the mode where multiple command line headers would each produce a single C++ standard header unit) ..
Nov 3 2022
Nov 1 2022
Oct 19 2022
Oct 18 2022
once again we are getting off topic for this patch :)
Oct 17 2022
I am also OK with doing this in two steps (first in the driver with this patch and then by updating the FE to allow the two outputs from one invocation - my draft patch series).
LGTM (the CI test fail seems spurious/unrelated, and does not repeat for me on macOS)
Oct 13 2022
Oct 12 2022
To avoid more tangential discussion here - I've opened https://discourse.llvm.org/t/generating-pcm-module-interfaces-and-regular-object-files-from-the-same-compiler-invocation/65918 ... it would be great if the major stakeholders here especially @rsmith could comment on the design intentions.
Oct 11 2022
(trying not derail this discussion further)
- Yes, the alternate solution proposed for the "Hello World" case would work with the module mapper interface. However, the initial discussion was simply about being able to produce both the .PCM and .O artefacts from one invocation of the FE.
- It seemed reasonable to mention (since it's not vapourware, there are draft patches), but clearly some technical issues to address.
- I do not think this patch fully addresses the issue of harmonising GCC and clang's command lines for modular builds (because it does not deal with discovery of modular code in 'normally named' sources), and my investigation of trying to do this in the driver suggests that it would be much more complex than doing it in the FE.
Oct 10 2022
FAOD: I think this should not be about "who's patches" - but about the compilation model and command lines that we want to end up with.
@ChuanqiXu BTW, I think we (unfortunately) have some overlap in work in progress here;
Oct 1 2022
rebased and updated to elide the guard only for the case of no inits _and_ no imports.
Sep 26 2022
So, in light of these comments;
Sep 24 2022
thanks for the review.
address review comments, minor amendments to description.
rebased and reworked.
Aug 21 2022
Aug 20 2022
rebased, addressed remaing comments.
Aug 19 2022
Aug 17 2022
Aug 15 2022
rebased, addressed review comments
Aug 8 2022
general comment.
@h-vetinari you are right, this has become difficult to review - I will try and do some more later - just the one comment for now.
Aug 2 2022
Aug 1 2022
LGTM, one small point about the test,
Jul 25 2022
Jul 24 2022
Jul 23 2022
rebase, update testcases for upstream changes.