Tested this patch in https://github.com/conda-forge/llvmdev-feedstock/pull/198, can confirm it works. Thanks a lot!
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Sun, Mar 12
Feb 18 2023
Feb 12 2023
Just to confirm: I applied this patch to rc1 (& rc2) and then things build fine again. Thanks!
Feb 2 2023
Thanks for this!
Jan 24 2023
Jan 23 2023
Urgh, REALLY!? This is a revert of a serious memory regression. I think I'll need some level of more information? I'm not sure what is going on with it? @ChuanqiXu is one of my modules code owners, and perhaps sees something obvious?
Jan 16 2023
Cool!
Why abandon this revision? Wouldn't it be useful for this issue to have more visibility rather than less?
Jan 15 2023
Sorry for the misleading and thanks for the quick clarification. So it looks like the status quo is a little bit worse than I imaged...
In D137534#4055283, @ChuanqiXu wrote:@h-vetinari said it should be OK to backport these patches to branched 16.x.
Jan 12 2023
Jan 8 2023
BTW, the series of clang-scan-deps patch (https://reviews.llvm.org/D139168) is also necessary [...]
Jan 7 2023
Without undue haste, I just wanted to comment from the peanut gallery that it would be amazing if the patches that are necessary for CMake + Clang to use C++ modules would make the cut-off for LLVM 16 that's coming up around the 24th of January.
Dec 25 2022
Clang trunk doesn't claim support: https://godbolt.org/z/hes3nah8s. I'm actually quite surprised this doesn't break the CI. I remember having problems with at least Clang 15 when trying to use conditionally trivial special member functions.
Dec 9 2022
Dec 4 2022
I've had a small nit/suggestion post-merge of https://reviews.llvm.org/D138901; in case you feel it's worth picking up if you're touching that file already.
Nov 30 2022
I'd also use newlines more liberally since the two-space indentation is pretty dense already.
Nov 21 2022
@nadiasvertex
Any update on this?
Oct 27 2022
Congratulations for landing this!
Oct 26 2022
Oct 25 2022
Drive-by comments for consistency
Oct 18 2022
Sep 26 2022
Seems DR2621 is not yet listed in https://github.com/llvm/llvm-project/blob/main/clang/www/cxx_dr_status.html (but if it were, it should be updated...)
Sep 22 2022
Now I'm wondering why the attribute exists at all. If it's functionally equivalent to constexpr as a keyword, what are the use cases for the attribute?
Sep 21 2022
In D133853#3797598, @RIscRIpt wrote:I am afraid it would take me some effort to implement semantics of [[msvc::no_unique_address]], so I'd like to focus only on [[msvc::constexpr]] in current patch.
Aug 25 2022
In D131388#3748062, @ChuanqiXu wrote:Replace C++20 Modules with Standard C++ Modules since @ruoso pointed out that Modules is not specific to certain versions of C++ (for example, Modules may get some big changes in C++23, C++26, ...).
I have another question, probably mainly for @tstellar (since I don't understand the clang/tools/libclang/libclang.{exports,map} infrastructure). Now that we're defaulting back to the equality case, would we need to reinstate libclang.exports (probably conditional on CLANG_FORCE_MATCHING_LIBCLANG_SOVERSION == ON)?
Aug 23 2022
My concerns have already been raised by others in that thread and related issues, I see no point in restating them yet again. I don't see consensus, I see a handful of people discussing reverting a change that broke a whole bunch of assumptions made by real-world code.
Thanks for the review. Given that you have concerns, could you voice them in a larger forum (https://discourse.llvm.org/t/rationale-for-removing-versioned-libclang-middle-ground-to-keep-it-behind-option/64410), where so far the direction was in favour of going back to the status of LLVM 14 (but with an opt-out for those who prefer equality).
IMO looks good, thanks!
Aug 22 2022
Sorry it took me a while to respond, was AFK last week. This looks like a good start, I can try testing the instructions with the LLVM 15 builds (also RCs) and report back with what I find.
Aug 11 2022
In D129160#3716826, @isuruf wrote:Maybe this should be a cmake option that is off by default and I can turn it for my builds?
LGTM
Aug 9 2022
Are the rowspans here correct? For some reason https://clang.llvm.org/c_status.html is not being updated with this change.
Aug 8 2022
Thanks! Repeating a point that might have been overlooked from D131062 (this time not as comments in the diff to avoid the "pollution" that caused the move to this PR):
If you do open a new revision, please also consider breaking the lines at a length that phabricator doesn't overflow (seems to be 122 characters), and change all occurrences of "codes" to "code".
If you do open a new revision, please also consider breaking the lines at a length that phabricator doesn't overflow (seems to be 122 characters), and change all occurrences of "codes" to "code".
In D131062#3705864, @ChuanqiXu wrote:Yeah, I am also worrying if the comments may block other reviewers to review. Do you know any method to ignore these comments in phab? If not, I guess I need to create a new page (but this is what we want?)
It gets very confusing that phab now attaches the old review comments in the wrong place.
Aug 6 2022
It would be greatly welcome for such comments!
Aug 4 2022
That was the last algorithm in RangesAlgorithms.csv - congratulations! :)
Aside from a couple typos, I was wondering if it would be welcome to do a pass w.r.t stylistic improvements (e.g. "Modules have a lot of meanings." --> "The term 'modules' has a lot of meanings"). I don't want to be too nit-picky - the sentences are all understandable, but sometimes slightly unusual to a native speaker in their formulation.
There are still a few tests for these commented out, e.g. in:
libcxx/test/std/algorithms/ranges_robust_against_dangling.pass.cpp
libcxx/test/std/algorithms/ranges_robust_against_proxy_iterators.pass.cpp
libcxx/test/std/library/description/conventions/customization.point.object/niebloid.compile.pass.cpp
Aug 1 2022
Thanks for chasing these down!
Tested that this fixes the issue - thanks!
Jul 29 2022
My point boils down to: "written using standard C++17
code" does not sound at all like "core language, no stdlib", but very much like "core+stdlib".
From the text you quoted:
Jul 28 2022
It may be worth calling out that this is about C++17 core language and not the standard library?
The commit landed after LLVM 15 branched but still mentions that version in the release notes & CXX status. Is the intention that this'll be backported?
Jul 25 2022
In D129160#3678431, @tstellar wrote:@h-vetinari Does the release note look OK?
Jul 23 2022
How realistic is it that this still makes it into LLVM 15? I'd really like to start testing the pstl in our ecosystem a bit, happy to file bug reports too if so, but I'd need a way to be able to build it...
Jul 19 2022
Is it realistic for this to land before LLVM 15 branches? Would be great!
Jul 17 2022
Jul 14 2022
In D129195#3652046, @philnik wrote:In D129195#3650796, @h-vetinari wrote:Though you probably know, there's yet another DR on top of P1423 that has been accepted (only missing plenary vote): https://github.com/cplusplus/papers/issues/1171
Might be worth investigating to not needlessly introduce breakage that will then have to be undone again.
The paper you linked only changes core wording, so it shouldn't make any difference for the library part. Or am I missing something?
Jul 13 2022
Though you probably know, there's yet another DR on top of P1423 that has been accepted (only missing plenary vote): https://github.com/cplusplus/papers/issues/1171
We're currently focusing on ranges to get as much as possible into LLVM15. After that I want to work on std::pmr.
This PR didn't update the format status page. Is the warning from C++20 status still current?
P0645: The paper is implemented but still marked as an incomplete feature (the feature-test macro is not set and the libary is only available when built with LIBCXX_ENABLE_INCOMPLETE_FEATURES). Not yet implemented LWG-issues will cause API and ABI breakage.
Any update on this?
Jul 12 2022
Just comments, looks OK otherwise.
Jul 6 2022
Forgot to mention it before: would be good to note this in the release notes
Jul 5 2022
Thanks for the ping. It's unfortunate that this didn't work out as intended. It's certainly fine though (for our purposes) to go back to the way things were before.
May 19 2022
Should probably be mentioned in the release notes...?
May 17 2022
Very happy to see this finally happening! :)
May 3 2022
Apr 27 2022
2x "Buffer cannot by nullptr" -> "Buffer cannot be nullptr"
Apr 14 2022
Apr 13 2022
Speaking as a relative outside (but who's been waiting for flang in LLVM since well before it joined the monorepo), I'd much prefer code-generation-with-rough-edges in LLVM 15 (to start testing and raising eventual bugs), rather than a more polished flang (realistically still with bugs that need to be shaken out) in LLVM 16.
Apr 7 2022
Mar 26 2022
Mar 22 2022
Mar 9 2022
Something must have gone wrong... communication-wise... as @urnathan seems to have abandoned (resp. resigned from) all modules PRs. Hope any misunderstandings or grievances can be worked out!
Mar 2 2022
Feb 27 2022
A non-actionable comment out of curiosity for the work
Jan 24 2022
Just a nit/note before LLVM 14 branches: a few bullets in FormatPaper.csv should probably now be updated as well.
Congratulations on landing this huge piece of work, and even more so in time for LLVM 14!
Jan 13 2022
Ah, just saw your comment to that exact effect in the meantime. :)
OK, just taking the second half of the patch in openmp/libomptarget/deviceRTLs/amdgcn/CMakeLists.txt is actually enough for the backport.
Thanks a lot for the patch! I'm trying to figure out how to apply this to 13.0.0-rc2, but it's not obvious since https://reviews.llvm.org/D111983 has happened in between and reshuffled a bunch of things around.
Nov 8 2021
Oct 23 2021
Oct 11 2021
Given the cross-review of the respective authors, I'm assuming this is compatible / aligned with https://reviews.llvm.org/D111356? I ask because despite the mutual review, this wasn't mentioned in the email to LLVM-dev about the latter.
Sep 29 2021
I tested this patch in https://github.com/conda-forge/llvmdev-feedstock/pull/131 and it works as intended. Any blockers to landing it?