In D148546, I replaced much of the use of llvm::StringView w/
std::string_view. There's one important semantic difference between the
two:
In most STL containers, end() returns an iterator that refers to one
past the end of the container. But llvm::StringView::end() refers to the
last element.
Expressions such as `&*my_std_string_view.end()` produce the failed
assertion:
include/c++/v1/__iterator/bounded_iter.h:93: assertion
__in_bounds(__current_) failed: __bounded_iter::operator*: Attempt to
dereference an out-of-range iterator
This was caught when copying the recent downstream changes back upstream
in D148566, and is reproducible via:
$ libcxx/utils/ci/run-buildbot generic-debug-mode
when compiled with clang and clang++. The correct way to get the same
value as before without dereferencing invalid iterators is to prefer
`&*my_std_string_view.rbegin() + 1`.
Fix this downstream so that I might copy it back upstream in D148566.
The other instance of `&*my_std_string_view.end()` that I introduced in
D148546 has been fixed already in D149061.
Reviewed By: ashay-github
Differential Revision: https://reviews.llvm.org/D151760
std::string_view ProtoSourceName(Qual.data() + Len, Qual.size() - Len);
std::string_view Proto;
{
- ScopedOverride<const char *> SaveFirst(First, &*ProtoSourceName.begin()),
- SaveLast(Last, &*ProtoSourceName.end());
+ ScopedOverride<const char *> SaveFirst(First,
+ &*ProtoSourceName.begin()),
+ SaveLast(Last, &*ProtoSourceName.rbegin() + 1);
Proto = parseBareSourceName();
}
if (Proto.empty())