Rebase on top of D66437.
Wed, Feb 26
The diff between both changes might still be interesting.
On openSUSE we're running the llvm, clang, and libc++ test suite with just python3-base as dependency. This doesn't include the distro package, so it would be the first dependency outside of the Python standard library.
Tue, Feb 25
Mon, Feb 17
An alternative to this change would be to assume that distributions recent enough to have Python 3.8 also have /etc/os-release, which has become somewhat of a standard. So we could check if that file exists, then use it if it does and fallback to platform.linux_distribution() if it doesn't. Then we wouldn't need an additional dependency.
Committed in rG4f53867ec27bde33479c7891c256225f2075945a.
Fri, Feb 14
Just FYI, I had to fix some tests after this in rG705306526b5ca7eed2fa28ebf832873cbb5085ec.
Thu, Feb 13
This is for the release/10.x branch, not master. It mirrors rG24c2e53e770f5fe98d853ff04f035e3696b2cf60 and predecessors.
Tue, Feb 4
Sun, Feb 2
I've been thinking about the warning messages, which seem to a bit inaccurate. Sorry for piggy-backing this onto the change, I hope you don't mind.
Exactly, it would just be a bug fix.
Sat, Feb 1
@rsmith Could you have a look at this?
Thanks for the reviews! Do you think it makes sense to bring this to Clang 10?
Fri, Jan 31
Jan 26 2020
Looks right to me, but someone else should approve.
Jan 24 2020
Here is a proposal: we add two children to -Wrange-loop-analysis.
Jan 23 2020
one could also argue that this is a bit harder to follow in a range-based for loop.
This seems to be the argumentation of https://bugs.llvm.org/show_bug.cgi?id=32823#c0, so I guess it's Ok.
I think we can actually view this in more general terms, unrelated to range-based for loops.
Jan 21 2020
I also still think that warn_for_range_copy should be emitted even in templates.
Jan 20 2020
Yes, but minimal fix is better for release branch, so @hans should merge it.
As I wrote on the bug, I think we should only suppress one of the warnings in templates (and maybe always):
Jan 16 2020
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.
Jan 13 2020
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.
Jan 12 2020
@aaron.ballman We could make the warning even stricter, but that should be a separate discussion. Is this change Ok for now?
Jan 10 2020
Jan 9 2020
Without this patch, any project that wants to use this header needs to add a vendored copy of FDP to their source repository. With this patch, non-clang will still have to do this, though projects that build with clang will not.
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
The current change (without the racy test) looks good to me.
Nov 15 2019
The function I was suggesting marking used is the one passed to the linker as -fini, not the one marked destructor.
Nov 14 2019
Remove __kmp_internal_end_fini instead of exporting it: it shouldn't be needed.
Nov 13 2019
foreign thread should crash if library closed w/o shutdown
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?
As well as removing the __kmp_internal_end_fini symbol at all, as it duplicates the functionality of __kmp_internal_end_dtor which has attribute "destructor". I am OK with either solution, would be good to hear others opinion.
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
Both of these should first do overload resolution for one parameter of type MoveOnly&&, and then, only if that overload resolution fails, should they fall back to overload resolution for one parameter of type MoveOnly&.
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
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 30 2019
Sep 28 2019
Can be "reproduced" with clang -fsyntax-only -Wstrict-prototypes clang/include/clang-c/*.h.