- User Since
- Jul 12 2018, 4:43 PM (79 w, 4 d)
As I wrote on the bug, I think we should only suppress one of the warnings in templates (and maybe always):
Thu, Jan 16
Hmm, I have been wondering about this as well. The way I see it, all of these things are what we call capabilities, and we treat them all the same. The names are just meant to make warning messages more readable, because what the analysis considers a capability, the user might know as a mutex, or role, or sequence.
Mon, Jan 13
A fix would be to let all three produce exclusive negative capability, which essentially means there is no type associated with negative capability. This fix could also fix my bug.
Sun, Jan 12
@aaron.ballman We could make the warning even stricter, but that should be a separate discussion. Is this change Ok for now?
Fri, Jan 10
Thu, Jan 9
Dec 10 2019
Dec 5 2019
Already fixed via D66437.
Dec 3 2019
An alternative would be to assume that any distribution new enough to have Python 3.8 also has /etc/os-release, so we fall back to parsing that if platform.linux_distribution isn't there. Or the other way around: we check for /etc/os-release and fall back to platform.linux_distribution.
Dec 1 2019
@rsmith, could you please have a look?
Nov 23 2019
Nov 18 2019
Nov 15 2019
Nov 14 2019
Remove __kmp_internal_end_fini instead of exporting it: it shouldn't be needed.
Nov 13 2019
Nov 12 2019
I will try removing __kmp_internal_end_fini with a test that __kmp_internal_end_atexit is still called.
This is a larger effort so it will take a little bit more time on me.
Nov 7 2019
Let's say we remove __kmp_internal_end_fini and rely on __kmp_internal_end_dtor, can we write a test case ensuring that __kmp_internal_end_atexit is called? That calls into __kmp_task_team_wait, so maybe we can exit while some tasks are still running, and get a different observable result depending on whether we wait or not?
Nov 6 2019
Belatedly filed bug 43927. Feel free to comment there if you think this isn't the proper fix.
Nov 3 2019
Oct 31 2019
Oct 30 2019
Not answering inline because comments are getting longer.
Oct 29 2019
Add test case where check for non-deduced parameter conversions is necessary.
Oct 28 2019
Oct 19 2019
Oct 16 2019
@beanz Could you have a look again?
Oct 15 2019
Given the complexities of this implementation, I'm beginning to doubt whether implicit moves make sense for co_return at all. Since there can never be any kind of RVO, why not always require an explicit std::move? Implicit moves on return were introduced because an explicit move would inhibit NRVO, and without move there wouldn't be a graceful fallback for implementations that don't have NRVO.
Add tests suggested by @Quuxplusone and add fallback to call by lvalue reference.
Oct 12 2019
@GorNishanov Do I read the standard correctly that there are no constraints on what return_value is? That is, could it also be a function pointer or function object?
I'll add your test case, but I'll probably reuse the existing data structures.
Oct 11 2019
Oct 10 2019
Also remove FIXME comment.
Please have a look at D68845. This should address the issues that we discussed.
@Quuxplusone Thanks for your very helpful comments!
Oct 9 2019
This change breaks the following code that worked before:
Oct 8 2019
Sep 30 2019
Sep 28 2019
Can be "reproduced" with clang -fsyntax-only -Wstrict-prototypes clang/include/clang-c/*.h.
Handle static libraries correctly.
I didn't know about this patch and published D68172: adding BUILDTREE_ONLY still builds the examples, but doesn't install them. It's also used by other test plugins like llvm/lib/Transforms/Hello.
Thanks to @lebedev.ri for informing my about this patch.
Sep 27 2019
Sep 25 2019
This change does not affect the Clang triple, that is and will be powerpc-unknown-linux-gnu. It's just about where Clang looks for the GCC toolchain.
Sep 21 2019
Perhaps I should mention that this fixes an assertion failure.
Pass correct Clang triple as argument to --target.
Sep 9 2019
Sep 7 2019
I'm thinking about the following, but I'm not sure if that's the proper way to do it.
Sep 4 2019
Sep 3 2019
Remove wrong changes in SemaExprCXX.cpp.
If anyone shares my feeling that the boolean output parameters of CompareReferenceRelationship should rather move to the return value, I would be happy to do that.
Sep 2 2019
Thank you for having a look at the notes, that's good to hear.
Aug 30 2019
IIRC, when we rolled out -Wstrict-prototypes we explicitly excluded this case since it hit a lot of code without finding bugs.
We had a discussion on IRC yesterday and @aaron.ballman pointed out that the K&R syntax has been considered "obsolescent" (= deprecated) since C89, 30 years ago. He added that there are thoughts within the standards committee about removing the syntax entirely from C2x.
Aug 29 2019
By the way, I'm open to adding a fix-it hint for zero-parameter K&R-style definitions, since the fix is pretty straightforward.
"Meaning" is a difficult term. What we know is that this is a K&R-style definition, and does not define a prototype. So one would expect -Wstrict-prototypes to warn about this.
Aug 28 2019
Note that I'm just copying GCC, which seems the be the original intent behind the warning (https://bugs.llvm.org/show_bug.cgi?id=20796). So people who use both compilers will have seen that warning already. Note also that there is no warning if any declaration provides a prototype, so this is fine:
Added a test case, verified that it fails before the change.
Aug 10 2019
Sorry for warming this up again, but it would be nice to get rid of this patch in openSUSE.