- User Since
- Jul 12 2018, 4:43 PM (153 w, 45 m)
Mon, Jun 14
Wed, Jun 9
Sat, Jun 5
Thu, May 27
Right, although assertions can turn into no-ops depending on the build profile. We discussed this on D87629.
The complexity for -Wweak-template-vtables is just 10 lines of code. We're just using information that's already there.
Thank you as well!
Tue, May 25
Essentially I'm suggesting here to treat exclusive/shared joins the same way as locked/unlocked joins: we allow them for managed locks and take the "weaker" state afterwards to prevent false negatives, but not for unmanaged locks, where we take the "stronger" state afterwards to prevent spamming the user.
Fri, May 21
Not sure if it's simpler, but it'll produce less confusing results.
Thu, May 20
Reverting back to original change. I think it's the only thing that works.
Hmm, this doesn't actually work. The problem is that we're using target_link_libraries with LLVMTableGen, which we have to, because it's not in the big shared library. But then we also get the dependencies of that (LLVMSupport and LLVMDemangle), which are part of the shared library. In my experiments there wasn't a problem, but that might just be a coincidence.
May 14 2021
Again, I'm not sure if it helps to use getDecltypeForParenthesizedExpr where we don't actually have the decltype of a parenthesized expression.
@aaron.ballman, what do you think about this? We can't really prevent anyone from writing .getValueKind() == VK_*Value instead of .is*Value(), so this change will make things consistent only for now.
May 13 2021
Ping @aaron.ballman, also for the parent change.
May 7 2021
(I think you have to squash the changes, Arcanist seems to take only the last commit.)
Somehow the patch got messed up, I think. The changes that I see look like the changes since the previous patch, not the new patch.
May 6 2021
May 5 2021
This is useful for creating daily snapshot tarballs that can easily be consumed by packagers who want to build a daily snapshot.
May 3 2021
No, I fear that would take too much time. (Not so much the benchmarking, but making a number of fixes that can be expected to make a dent.)
Apr 30 2021
So I tried this in two code bases, both of which don't have -Wweak-vtables enabled though.
- Fix punctuation in expected warning message.
- Fix test failure: the instantiated class might not be a template, it could also be the member of another template.
Apr 29 2021
Well, except that this isn't a new warning. But yeah, it does make sense to look at some actual code bases.
That was a valid reason, but now there are code bases that work with -Weverything and disable the warnings they are not interested in.
Apr 23 2021
Apr 19 2021
Apr 18 2021
The change seems to be correct, but I'm wondering if x.getValueKind() == VK_*Value doesn't have one advantage over x.is*Value(): it's obvious that this is exclusive with the other values. Especially with isRValue() it might not be so obvious, because Clang doesn't follow the C++11 terminology with this.
Apr 17 2021
It seems that using is*Value and the introduction of getDecltypeForParenthesizedExpr could be two separate changes.
Apr 14 2021
Apr 13 2021
Apr 11 2021
Apr 10 2021
Apr 9 2021
Didn't really check for correctness yet, just a superficial review.
Apr 6 2021
Apr 1 2021
@beanz, Phabricator still treats this as accepted, but I'd appreciate if you have another look at it.
I'm wondering if we should move the files to their respective subprojects, but that would probably prevent the links from working. So I guess we have to live with this for now.
Mar 31 2021
Let's do it the CMake 3.13 way, that seems to work even with the object library hack in add_tablegen.
It seems that everything is fine with ninja, but with make we're running into this fun hack:
Go back to object library instead.
Mar 30 2021
On the other hand, if llvm-tblgen is not meant to link with the LLVM dylib, maybe the unit test for TableGen should also be standalone? Which would be an argument for the change as it is.
Not only that, you also want to use them in TableGenTests, and this I think is why can't just have them in llvm-tblgen.
The comments apply similarly to the other files,
Mar 29 2021
Agreed, we don't want to duplicate them.
Mar 28 2021
Replace E->getType() argument by T.
Mar 27 2021
@thakis, now that we require CMake 3.13.4, would you be fine with going back to an object library?
This generates a man page for xxx-tblgen, though arguably no such tool exists.
Mar 25 2021
Mar 24 2021
Not replying in order, I hope that's not confusing. Let's start with the motivation.
Mar 23 2021
I thought maybe you wanted to follow @mizvekov's proposal to simplify, but I understand you want to stick close to the standard language.
Mar 21 2021
With my previous comment I meant that it's better if you leave out the co_return bits for now because it's wrong anyway. We can't use PerformMoveOrCopyInitialization. It would just generate merge conflicts.
Mar 20 2021
For coroutines I have D68845. The current code is wrong, and not trivial to fix. We have never properly implemented P1825 and will probably just go with P2266 unconditionally, because that two-phase lookup is very cumbersome to imlement.
Mar 19 2021
Mar 18 2021
Negative capabilities don't need to be considered as managed.