User Details
- User Since
- Sep 16 2014, 4:54 AM (481 w, 4 d)
Oct 3 2023
although this was approved, we did not need to use it to implement the dependent changes.
this is now
https://github.com/llvm/llvm-project/pull/68076
Sep 11 2023
sorry I did not get to moving this yet - but will try during this week.
Sep 2 2023
Aug 26 2023
Some background since it is relevant to the testing done so far.
Jul 14 2023
on the subject of is there any way to diagnose:
- if we encounter either a linker-visible or global symbol after a cfi_startproc but before the next cfi_endproc [in the same section], that would seem to indicate bad nesting?
- I suppose that there could be some weird code-gen that multiplexed the output between sections, so seeing a section switch before the closing cfi_endproc is not sufficient
Jul 4 2023
Jul 3 2023
Jul 1 2023
changes are needed to address review comments - but this revision is needed as a parent to other work (so might need to be rebased from time to time)
rebased, fixed some format issues; again to support p1815 work only.
Jun 30 2023
just rebased to support p1815 work
Jun 26 2023
need to re-check that the intention of the paper is covered (since we currently treat bare 'export' and 'export {}' in a similar manner).
Jun 25 2023
Jun 24 2023
Jun 22 2023
rebased and fixed some formatting.
I think it is a good idea to keep this part of P2615R1 separate from the unnamed exports diagnostics [the parent commit] - it seems likely that there will be more fallout from this (given that there were already PRs about the behaviour of exported specialisations).
not sure why the debian CI is reported clang-format errors; I am not seeing them here.
rebased, addressed review comments.
Jun 21 2023
Jun 19 2023
I will look at the rest of the comments once back in the office.
Jun 14 2023
thanks to Daniela Engert for reporting this and helping identify the current WG21 status on the topic.
Jun 12 2023
rebased, added testcase for Issue 61601.
although I would welcome input from the ABI owners, testing shows that this patch does appear to DTRT and brings clang in line with the operation of GCC in this area. It would be good to land it (or decide what other action is needed) before 17 branches
many thanks to Daniela Engert from bringing this to my attention (and providing a reproducer test case).
Jun 9 2023
about the comments that the patch seems to do multiple things; I do not think we can fix the lookup without touching the typo-fixes since it uses the same underlying machinery - if we do not adjust the typo fixes, we will regress diagnostics.
rebased and adjusted for upstream changes
BTW, I am generally very uncomfortable with making the deserialisation process do more of the Sema work.
Actually, P1815 is almost complete (95%+ in the current patch and i am currently looking at the lambda) however P1815 is ultimately blocked by this (lookup) issue; That is, P1815 is not a solution to the lookup problem - for it to work lookup has to be fixed.
May 24 2023
This looks reasonable to me - but the vtable stuff is not an area that I am familiar with, so I'll defer to the other reviewers.
Apr 6 2023
in the end, we have to deal with the following cases:
rebased, addressed review comments (patch still needs refactoring)
Apr 2 2023
I updated this because I am going to push the latest version of the P1815 patch and that depends on the lookup changes.
rebased
Mar 31 2023
Mar 29 2023
Mar 28 2023
rebased, retested.
+1 for this as an interim solution.
Mar 27 2023
It took me a while to get my local macOS based devt. environment to reproduce the problem - but it was as expected; the implementation module was unowned and nothing was deleting it.
rebased, reworked to have the module owned.
I had a hunch that the issue was the non-ownership of the implementation module.
Mar 26 2023
Mar 24 2023
although this patch does handle the cases needed, it really needs refactoring.
posting here since we are both working in this area and this might be useful input.
rebased, split the changes to module and private linkage out,
Mar 23 2023
Mar 22 2023
rebased, addressed review comments, and amended the description.
I agree it is complex
- I think it needs more than is in this patch
- and there are different rules applied during lookup for typos (which I have had to handle specially, otherwise we get useless suggestions)
Mar 19 2023
rebased.
Mar 17 2023
General comments (at least my opinion).
Mar 16 2023
This was originally created (and @ChuanqiXu approved) for the work on module initialisers. I did not apply it then, since it was possible to determine the correct state for the initialisers without it.
rebased, and reworked for changes in main.
Mar 15 2023
Mar 14 2023
Mar 13 2023
I should definitely check to make sure that this was adopted as a DR against C++20 (otherwise we would need to use the previous test conditionally on < 2b).
Mar 2 2023
OK, I guess one extra sub-module is not too bad.
LGTM.
Feb 28 2023
Feb 27 2023
Feb 20 2023
OK - the visibility path is already complex, we do not need to make it more so.
I guess you are intending to rebase/update this?
I am wondering why we need to add another sub-module.
Feb 2 2023
Jan 31 2023
rebased, added tests for instantiated variable/function templates.
Jan 30 2023
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?
Jan 29 2023
AFAICT the failing test is unrelated to this patch.
Jan 28 2023
in my local testing, I was able to consume all libc++ headers individually.
rebased, and revised to handle variable templates and instantiations.
Jan 27 2023
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).