@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.

In D51741#1702038, @Quuxplusone wrote:

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&.

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!

In D51741#1702038, @Quuxplusone wrote:

This patch is heavily heavily merge-conflicted by P1825.

This change breaks the following code that worked before:

Gentle ping.

In D67112#1655937, @aaronpuchert wrote:

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.

Ping?

Fixed by @aaron.ballman in rC373213 along with another issue.

Can be "reproduced" with clang -fsyntax-only -Wstrict-prototypes clang/include/clang-c/*.h.

Fix typo.

Handle static libraries correctly.

In D67877#1686961, @Jiboo wrote:

@Szelethus could you confirm that thus examples shouldn't be built when CLANG_BUILD_EXAMPLES is OFF, and that this patch is still valid?

In D68172#1686960, @Szelethus wrote:

The patch looks alright, I won't formally accept because if I knew how these worked, it wouldn't have caused so much pain to so many people :)

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.

In D68172#1686772, @NoQ wrote:

+@Szelethus because i'm a bit out-of-the-loop on plugins: i very vaguely remember that we decided to put them into tests(?)

In D55326#1342412, @nemanjai wrote:

A couple of questions since I am not all that familiar with clang and am certainly not familiar with this unusual SUSE 32-bit situation:

• We seem to be changing the set of aliases here, but what happens if someone actually explicitly specifies --target=powerpc-suse-linux?
• Can you describe the default triple for clang on SUSE 32-bit PPC? Will it be powerpc-suse-linux? powerpc64-suse-linux?

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.

Perhaps I should mention that this fixes an assertion failure.

Pass correct Clang triple as argument to --target.

I'm thinking about the following, but I'm not sure if that's the proper way to do it.

In D66919#1658355, @aaron.ballman wrote:

We do have numerous warnings that are default errors, you can look for DefaultError in the diagnostic .td files to see the uses.

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.

In D66919#1655048, @dexonsmith wrote:

I went back to read notes from when we deployed -Wstrict-prototypes (which we have had on-by-default for our users for a couple of years, since it catches lots of -fblocks-related bugs). I was mainly objecting because I had (mis)remembered trying and backing out the specific behaviour you're adding. On the contrary, our notes say that we might want to strengthen the diagnostic as you're doing.

Thank you for having a look at the notes, that's good to hear.

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.

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.

In D66919#1651108, @dexonsmith wrote:

we just don't warn on non-prototype defining declarations, where the meaning is unambiguous:

void foo() {}

"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.

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.

Sorry for warming this up again, but it would be nice to get rid of this patch in openSUSE.

In D41296#962215, @hfinkel wrote:

Why don't we just cap all names at some point (and then just start adding numbers as we generally do to break degeneracies). It seems like, otherwise, we'll end up with these kinds of fixes in many places. Fixing this in one common place seems better.

The primary purpose of Thread Safety Analysis is to make sure that accesses to shared resources are protected. That's why we only track whether a lock is available by default (i.e. without -Wthread-safety-negative), locks that we don't know anything about are assumed to be unlocked. As a side effect, we can detect double unlocks and lock/unlock-kind mismatches.

What distinguishes a shared from an exclusive negative capability? Negative capabilities (as I understand them) express the mutex not being held at all, meaning neither in shared nor in exclusive mode.

Thanks for the reviews!

Remove -enable-split-dwarf completely, adapting the test case accordingly. Also remove -split-dwarf which wasn't used at all.

Sorry for making the inline comments disappear, but I had to switch to the big repository.

Make sure the flags have the same meaning for LTO. Also slightly reworded the HelpText.

Add checks that we don't emit the fix-it when we shouldn't.

In D59673#1521413, @dblaikie wrote:

Might be easier as a few patches - renaming the existing option,

D63130

adding the new one,

This change.

then removing the single split dwarf flag handling in favor of implying that by the absence of an output file name. (if I'm reading what this patch does)

D63167

Correct an oversight.