Thanks @lichray

Fixed incorrect test case.

In D38831#952228, @lichray wrote:

[...]test/std/utilities/meta/meta.rel/is_nothrow_invocable.pass.cpp:118:9: error: static_assert failed due to requirement '!std::is_nothrow_invocable_r_v<int, Fn>' ""
        static_assert(!std::is_nothrow_invocable_r_v<int, Fn>, "");
        ^             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.
--

with Clang-5.0 and trunk. Can you reproduce?

Turn fail test into SFINAE based pass test, mark XFAIL for clang.

Back to decltype-based SFINAE.

Full context diff.

Addressed review comments. Added tests for SFINAE, noexcept, deduction guide.

In D38831#917439, @EricWF wrote:

@K-ballo I always forget. Do you have commit access?

Fix synopsis

LGTM

I don't see any potential layout change, other than the case in which both T1 and T2 are empty (which I understand doesn't happen within libc++). As far as I know, the rest of the cases should result in the same layout regardless of whether EBO actually applies or not.

I like this!

LGTM

Addressed review comments. Use UNSUPPORTED in pairs.by.type.pass.

Addressed review comments

In D14839#306306, @EricWF wrote:

int x = 42;
int const y = 43;
std::pair<int&, int const&> const p(x, y);
static_assert(std::is_same<int const&, decltype(std::get<0>(std::move(p)))>::value, "");
static_assert(std::is_same<int const&, decltype(std::get<1>(std::move(p)))>::value, "");

I assume you agree that this test has the correct behavior?

After that these changes LGTM. @K-ballo I'm happy to make the changes as I commit this if your OK with that?

In D6964#241105, @EricWF wrote:

@K-ballo May I commit this with a couple of small changes? I want to fully qualify all of the calls to "declval<Tp>(...)".

In D10997#200911, @EricWF wrote:

Can I commit this for you?

In D10997#200672, @EricWF wrote:

I don't think we need any changes in __functional_03 because we don't provide bind in 03 :)

Waiting for VS2015RTM

Waiting for VS2015RTM

Waiting for VS2015RTM

Waiting for VS2015RTM

In D10191#187322, @EricWF wrote:

@K-ballo Do you want me to commit this for you?

Addressed review comments:

In D6964#164655, @EricWF wrote:

Just so I'm sure I understand: This implementation applies decay<T> for ever pair of types in common_type<T...> even though N2408 says decay is only applied to the final type?

After we found some corner cases where my simpler approach does the wrong thing, I think Eric's patch is the way to go.

The current functionality is correct as LWG2420 has not yet been accepted (note I'm the submitter). I'm sitting on a patch to implement the currently intended resolution (apply change to INVOKE, not just function) in a considerably simpler way, waiting for that direction to be confirmed.

SVN r227384

Address review comments.

Addressed review comments. Added test for the newly introduced diagnostic.

In D7111#112810, @mclow.lists wrote:

The fix looks reasonable, it fixes the OP's problem, and the new test fails w/o the fix.

However, the change to <regex> is in two places, and I don't see how this test exercises both code paths.

Any suggestions on what to do with the failing testcase (CodeGenCXX/no-opt-volatile-memcpy.cpp)? This test checks that the issued @llvm.memcpy has isvolatile=true, but after this patch memcpy is no longer issued as those operations are no longer considered trivial. This could suggest that memcpy with isvolatile=true should still be used in those cases (albeit the docs say "it is unwise to depend on it"), or that there is dead code out there looking for volatile members in trivial operations.

Addressed review comments. Keep in mind that only pow is implemented completely, once we get that one right I'll update the others to follow.

Updated test to work under C++03 mode

This patch reverts the incorporation of __lazy_enable_if, as this is a more general solution. It implements __numeric_type in a SFINAE-friendly fashion, which will flag ambiguously convertible UDTs (as well as other soft errors) as non-numeric types.

In D5127#4, @mclow.lists wrote:

Do we need tests for this change?

Looks good to me. Some notes attached.

Landed in rL218461

Addressed review comments

Use _LIBCPP_ALWAYS_INLINE as it seems a better choice.

Have you considered a non-recursive implementation of __tuple_constructible_imp? For instance, checking whether foo(declval<Up>()...) is well-formed given void foo(Tp...).

The existing implementation is the correct one for C++11, where is_destructible<T> is defined as:

In D4130#13, @rnk wrote:

Do you need me to commit this for you?

Changes in this iteration:

Changes in this iteration:

Changes in this iteration:

I would like to add a test case that triggers a table rehash but I'm not sure how to do that, suggestions?

Not sure, actually. It looks like the growth function is the usual sort of thing, so probably just inserting a second element should cause a rehash - no?

Changes in this iteration:

In the other code review you mention StringMap has an insert that
returns bool? Yet you're not modifying that version here? What
arguments does it take that make it distinct from the two functions
you're adding?

The existing insert is defined as bool insert(MapEntryTy *KeyValue), it takes a pointer to an already created MapEntryTy and acquires ownership of it. AFAIK, this is the only piece of functionality that would not be covered by a standard associative sequence interface.

Do any of the callers (at a glance) do anything fancy with this? Do they get a pre-allocated MapEntryTy object from somewhere far flung (from another map, from this map under another key, etc) - or do they just allocate it and pass it in immediately?

If it doesn't seem to add any value, it'd be nice to remove it (eventually - that task doesn't have to be yours to bear, but if it looks like that's the right path then a FIXME comment suggesting that direction could be useful).

In D4153#4, @dblaikie wrote:

The test case looks a bit thin - it doesn't test the return value of
insert, only tests one of the two insert functions the patch
introduces, and doesn't test positive and negative cases of insert
(pre-existing element and new insertion)

I think that instead of introducing a new function I should just be using mangleSourceName. A template instantiation name is a source name too (considering anonymous type names are treated as source names), it's just that their terminating '@' is currently being added at the end of the template argument list. If the argument list no longer appends the '@', then they would be treated as any other source name.

In D4130#6, @timurrrr wrote:

Is it hard to add that function to the interface?

Commited in r210416.

Renamed BackReferenceKey to TemplateMangling