Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ADL-proof container operations for iterator pairs and comparators #4258

Merged

Conversation

frederick-vs-ja
Copy link
Contributor

@frederick-vs-ja frederick-vs-ja commented Dec 13, 2023

Towards #140. Some changes were already done in #4217.

Unblocks one libcxx test:

  • std/strings/basic.string/string.modifiers/robust_against_adl.pass.cpp

Notes:

  • There're some other internal function names qualified in changed functions.
  • Occurences of _Adl_verify_range are consistently _STD-qualified in touched headers.

@frederick-vs-ja frederick-vs-ja requested a review from a team as a code owner December 13, 2023 16:40
@CaseyCarter CaseyCarter added the bug Something isn't working label Dec 13, 2023
@StephanTLavavej StephanTLavavej self-assigned this Dec 16, 2023
_Insert_counted_range(_Where, _UFirst, _Count);
#ifdef __cpp_lib_concepts
} else if constexpr (forward_iterator<_Iter>) {
const auto _Length = _To_unsigned_like(_RANGES distance(_UFirst, _ULast));
const auto _Length = _STD _To_unsigned_like(_RANGES distance(_UFirst, _ULast));
const auto _Count = _Convert_size<size_type>(_Length);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this line also be changed?

Regex-searching for (?<!_STD )(_Adl_verify_range|_Get_unwrapped|_Convert_size|_To_unsigned_like|_Allocate_at_least_helper|_Uninitialized_\w+|_Destroy_range|_Move_backward_unchecked|_Copy_n_unchecked4), I see 75 unchanged occurrences in <vector>. Some I understand (e.g. an initializer_list always has size_t for its size(), so we don't need to worry about ADL), but I don't understand why others aren't being changed.

Since a bunch of lines are potentially affected and I don't totally understand what's happening here, I won't push changes. We can deal with this in a followup.

Copy link
Member

@CaseyCarter CaseyCarter Jan 12, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The result of _To_unsigned_like is always an integer-like type. It either has no associated namespaces - if it's integral - or we control the associated namespaces - if it's integer-class. (Recall that integer-like types are either integral or integer-class, and that integer-class types are only implementation-provided.)

I'm concerned that we seem to be developing more and more complex rules to determine when to _STD-qualify calls; maybe we should just qualify everything? (I think I may have started this by not qualifying _Ubegin and _Uend calls.)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

BTW I was asking about qualifying _Convert_size here, since the occurrence immediately above was changed.

At this point I think we should just qualify everything, if we want to defend against this ADL thing. It's too hard to enforce consistency otherwise. Same rationale as _STD qualifying all pretty calls regardless of arguments or lack thereof.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

BTW I was asking about qualifying _Convert_size here, since the occurrence immediately above was changed.

Yes - I understood this, I was explaining that we don't need to qualify the _Convert_size call since we control the argument type and can ensure that ADL is "safe".

At this point I think we should just qualify everything, if we want to defend against this ADL thing. It's too hard to enforce consistency otherwise. Same rationale as _STD qualifying all pretty calls regardless of arguments or lack thereof.

+1 from me.

Comment on lines 174 to +175
T another(begin(c), end(c));
T another2(begin(c), end(c));
T another2(begin(c), end(c), value.get_allocator());
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No change requested: Nice catch!

@StephanTLavavej
Copy link
Member

Thanks! I pushed a conflict-free merge with main, followed by a tiny test fix.

I have one outstanding question but it shouldn't block this PR.

@StephanTLavavej StephanTLavavej removed their assignment Jan 12, 2024
@StephanTLavavej StephanTLavavej self-assigned this Jan 17, 2024
@StephanTLavavej
Copy link
Member

I'm mirroring this to the MSVC-internal repo - please notify me if any further changes are pushed.

@StephanTLavavej StephanTLavavej merged commit 80e0909 into microsoft:main Jan 17, 2024
35 checks passed
@StephanTLavavej
Copy link
Member

😸 📦 🛡️

@frederick-vs-ja frederick-vs-ja deleted the adl-proof-cont-iter-op branch January 17, 2024 11:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants