Changes in regex

dab6463e748aed1223487da536075cbff192940b - [libc++] Remove duplicated _LIBCPP_HIDE_FROM_ABI from a few declarations (#122323)

Fri, 10 Jan 2025 16:42:42 +0000

[libc++] Remove duplicated _LIBCPP_HIDE_FROM_ABI from a few declarations (#122323) List of files: /llvm-project/libcxx/include/regex

f69585235ec85d54e0f3fc41b2d5700430907f99 - [libc++] Put _LIBCPP_NODEBUG on all internal aliases (#118710)

Wed, 08 Jan 2025 16:12:59 +0000

[libc++] Put _LIBCPP_NODEBUG on all internal aliases (#118710)This significantly reduces the amount of debug information generated for codebases using libc++, without hurting the debugging experience. List of files: /llvm-project/libcxx/include/regex

b9a2658a3e8bd13b0f9e7a8a440832a95b377216 - [libc++][C++03] Use `__cxx03/` headers in C++03 mode (#109002)

Sat, 21 Dec 2024 12:01:48 +0000

[libc++][C++03] Use `__cxx03/` headers in C++03 mode (#109002)This patch implements the forwarding to frozen C++03 headers asdiscussed inhttps://discourse.llvm.org/t/rfc-freezing-c-03-headers-in-libc. In theRFC, we initially proposed selecting the right headers from the Clangdriver, however consensus seemed to steer towards handling this in thelibrary itself. This patch implements that direction.At a high level, the changes basically amount to making each publicheader look like this:```// inside #ifdef _LIBCPP_CXX03_LANG# include <__cxx03/vector>#else // normal content#endif```In most cases, public headers are simple umbrella headers so there isn'tmuch code in the #else branch. In other cases, the #else branch containsthe actual implementation of the header. List of files: /llvm-project/libcxx/include/regex

c166a9c713ec86b86f1f178a5133bc128fd0a610 - [libc++] Add #if 0 block to all the top-level headers (#119234)

Tue, 10 Dec 2024 15:02:12 +0000

[libc++] Add #if 0 block to all the top-level headers (#119234)Including The frozen C++03 headers results in a lot of formattingchanges in the main headers, so this splits these changes into aseparate commit instead.This is part ofhttps://discourse.llvm.org/t/rfc-freezing-c-03-headers-in-libc. List of files: /llvm-project/libcxx/include/regex

c6f3b7bcd0596d30f8dabecdfb9e44f9a07b6e4c - [libc++] Refactor the configuration macros to being always defined (#112094)

Wed, 06 Nov 2024 09:39:19 +0000

[libc++] Refactor the configuration macros to being always defined (#112094)This is a follow-up to #89178. This updates the `<__config_site>`macros. List of files: /llvm-project/libcxx/include/regex

ba87515fea90b5d55836a8e3be63a7e683ce299d - [libc++][RFC] Always define internal feature test macros (#89178)

Sat, 12 Oct 2024 07:49:52 +0000

[libc++][RFC] Always define internal feature test macros (#89178)Currently, the library-internal feature test macros are only defined if the feature is not available, and always have the prefix `_LIBCPP_HAS_NO_`. This patch changes that, so that they are always defined and have the prefix `_LIBCPP_HAS_` instead. This changes the canonical use of these macros to `#if _LIBCPP_HAS_FEATURE`, which means that using an undefined macro (e.g. due to a missing include) is diagnosed now. While this is rather unlikely currently, a similar change in `<__configuration/availability.h>` caught a few bugs. This also improves readability, since it removes the double-negation of `#ifndef _LIBCPP_HAS_NO_FEATURE`. The current patch only touches the macros defined in `<__config>`. If people are happy with this approach, I'll make a follow-up PR to also change the macros defined in `<__config_site>`. List of files: /llvm-project/libcxx/include/regex

17e0686ab1107a1a675d8783383dedf70fa24033 - [libc++][NFC] Use [[nodiscard]] unconditionally (#80454)

Thu, 12 Sep 2024 19:18:43 +0000

[libc++][NFC] Use [[__nodiscard__]] unconditionally (#80454)`__has_cpp_attribute(__nodiscard__)` is always true now, so we might as well replace `_LIBCPP_NODISCARD`. It's one less macro that can result in bad diagnostics. List of files: /llvm-project/libcxx/include/regex

748023dc3210533df2c1c6efc8af1b5954493701 - [libc++][NFC] Replace _LIBCPP_NORETURN and TEST_NORETURN with [[noreturn]] (#80455)

Wed, 11 Sep 2024 06:59:46 +0000

[libc++][NFC] Replace _LIBCPP_NORETURN and TEST_NORETURN with [[noreturn]] (#80455)`[[__noreturn__]]` is now always available, so we can simply use the attribute directly instead of through a macro. List of files: /llvm-project/libcxx/include/regex

3d18cea904391f510ffd754713ce4e1731845ffb - [libc++][regex] Add _LIBCPP_FALLTHROUGH to suppress fallthrough warning (#100821)

Fri, 23 Aug 2024 16:40:38 +0000

[libc++][regex] Add _LIBCPP_FALLTHROUGH to suppress fallthrough warning (#100821) List of files: /llvm-project/libcxx/include/regex

59e56eeb1d9c0d25a522ae09f501a350981a31de - Revert "Reapply "[Clang] Implement resolution for CWG1835 (#92957)" (#98547)"

Mon, 15 Jul 2024 10:48:09 +0000

Revert "Reapply "[Clang] Implement resolution for CWG1835 (#92957)" (#98547)"This reverts commit ce4aada6e2135e29839f672a6599db628b53295d and afollow-up patch 8ef26f1289bf069ccc0d6383f2f4c0116a1206c1.This new warning can not be fully suppressed by the`-Wno-missing-dependent-template-keyword` flag, this gives developer notime to do the cleanup in a large codebase, see https://github.com/llvm/llvm-project/pull/98547#issuecomment-2228250884 List of files: /llvm-project/libcxx/include/regex

ce4aada6e2135e29839f672a6599db628b53295d - Reapply "[Clang] Implement resolution for CWG1835 (#92957)" (#98547)

Thu, 11 Jul 2024 22:49:35 +0000

Reapply "[Clang] Implement resolution for CWG1835 (#92957)" (#98547)Reapplies #92957, fixing an instance where the `template` keyword was missing prior to a dependent name in `llvm/ADT/ArrayRef.h`. An _alias-declaration_ is used to work around a bug affecting GCC releases before 11.1 (see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94799) which rejects the use of the `template` keyword prior to the _nested-name-specifier_ in the class member access. List of files: /llvm-project/libcxx/include/regex

d3923354a4c96f20c09b3991afb8c30804ed7a21 - Revert "[Clang] Implement resolution for CWG1835 (#92957)"

Wed, 10 Jul 2024 02:41:11 +0000

Revert "[Clang] Implement resolution for CWG1835 (#92957)"ppc64le-lld-multistage-test has been failing.This reverts commit 7bfb98c34687d9784f36937c3ff3e735698b498a. List of files: /llvm-project/libcxx/include/regex

7bfb98c34687d9784f36937c3ff3e735698b498a - [Clang] Implement resolution for CWG1835 (#92957)

Tue, 09 Jul 2024 23:00:19 +0000

[Clang] Implement resolution for CWG1835 (#92957)CWG1835 was one of the many core issues resolved by P1787R6: "Declarations and where to find them" (http://wg21.link/p1787r6). Its resolution changes how member-qualified names (as defined by [basic.lookup.qual.general] p2) are looked up. This patch implementation that resolution. Previously, an _identifier_ following `.` or `->` would be first looked up in the type of the object expression (i.e. qualified lookup), and then in the context of the _postfix-expression_ (i.e. unqualified lookup) if nothing was found; the result of the second lookup was required to name a class template. Notably, this second lookup would occur even when the object expression was dependent, and its result would be used to determine whether a `<` token is the start of a _template-argument_list_. The new wording in [basic.lookup.qual.general] p2 states: > A member-qualified name is the (unique) component name, if any, of > - an _unqualified-id_ or > - a _nested-name-specifier_ of the form _`type-name ::`_ or _`namespace-name ::`_ > > in the id-expression of a class member access expression. A ***qualified name*** is > - a member-qualified name or > - the terminal name of > - a _qualified-id_, > - a _using-declarator_, > - a _typename-specifier_, > - a _qualified-namespace-specifier_, or > - a _nested-name-specifier_, _elaborated-type-specifier_, or _class-or-decltype_ that has a _nested-name-specifier_. > > The _lookup context_ of a member-qualified name is the type of its associated object expression (considered dependent if the object expression is type-dependent). The lookup context of any other qualified name is the type, template, or namespace nominated by the preceding _nested-name-specifier_. And [basic.lookup.qual.general] p3 now states: > _Qualified name lookup_ in a class, namespace, or enumeration performs a search of the scope associated with it except as specified below. Unless otherwise specified, a qualified name undergoes qualified name lookup in its lookup context from the point where it appears unless the lookup context either is dependent and is not the current instantiation or is not a class or class template. If nothing is found by qualified lookup for a member-qualified name that is the terminal name of a _nested-name-specifier_ and is not dependent, it undergoes unqualified lookup. In non-standardese terms, these two paragraphs essentially state the following: - A name that immediately follows `.` or `->` in a class member access expression is a member-qualified name - A member-qualified name will be first looked up in the type of the object expression `T` unless `T` is a dependent type that is _not_ the current instantiation, e.g. ``` template struct A { void f(T* t) { this->x; // type of the object expression is 'A'. although 'A' is dependent, it is the // current instantiation so we look up 'x' in the template definition context. t->y; // type of the object expression is 'T' ('->' is transformed to '.' per [expr.ref]). // 'T' is dependent and is *not* the current instantiation, so we lookup 'y' in the // template instantiation context. } }; ``` - If the first lookup finds nothing and: - the member-qualified name is the first component of a _nested-name-specifier_ (which could be an _identifier_ or a _simple-template-id_), and either: - the type of the object expression is the current instantiation and it has no dependent base classes, or - the type of the object expression is not dependent then we lookup the name again, this time via unqualified lookup. Although the second (unqualified) lookup is stated not to occur when the member-qualified name is dependent, a dependent name will _not_ be dependent once the template is instantiated, so the second lookup must "occur" during instantiation if qualified lookup does not find anything. This means that we must perform the second (unqualified) lookup during parsing even when the type of the object expression is dependent, but those results are _not_ used to determine whether a `<` token is the start of a _template-argument_list_; they are stored so we can replicate the second lookup during instantiation. In even simpler terms (paraphrasing the meeting minutes from the review of P1787; see https://wiki.edg.com/bin/view/Wg21summer2020/P1787%28Lookup%29Review2020-06-15Through2020-06-18): - Unqualified lookup always happens for the first name in a _nested-name-specifier_ that follows `.` or `->` - The result of that lookup is only used to determine whether `<` is the start of a _template-argument-list_ if the first (qualified) lookup found nothing and the lookup context: - is not dependent, or - is the current instantiation and has no dependent base classes. An example: ``` struct A { void f(); }; template using B = A; template struct C : A { template void g(); void h(T* t) { this->g(); // ok, '<' is the start of a template-argument-list ('g' was found via qualified lookup in the current instantiation) this->B::f(); // ok, '<' is the start of a template-argument-list (current instantiation has no dependent bases, 'B' was found via unqualified lookup) t->g(); // error: '<' means less than (unqualified lookup does not occur for a member-qualified name that isn't the first component of a nested-name-specifier) t->B::f(); // error: '<' means less than (unqualified lookup does not occur if the name is dependent) t->template B::f(); // ok: '<' is the start of a template-argument-list ('template' keyword used) } }; ``` Some additional notes: - Per [basic.lookup.qual.general] p1, lookup for a member-qualified name only considers namespaces, types, and templates whose specializations are types if it's an _identifier_ followed by `::`; lookup for the component name of a _simple-template-id_ followed by `::` is _not_ subject to this rule. - The wording which specifies when the second unqualified lookup occurs appears to be paradoxical. We are supposed to do it only for the first component name of a _nested-name-specifier_ that follows `.` or `->` when qualified lookup finds nothing. However, when that name is followed by `<` (potentially starting a _simple-template-id_) we don't _know_ whether it will be the start of a _nested-name-specifier_ until we do the lookup -- but we aren't supposed to do the lookup until we know it's part of a _nested-name-specifier_! ***However***, since we only do the second lookup when the first lookup finds nothing (and the name isn't dependent), ***and*** since neither lookup is type-only, the only valid option is for the name to be the _template-name_ in a _simple-template-id_ that is followed by `::` (it can't be an _unqualified-id_ naming a member because we already determined that the lookup context doesn't have a member with that name). Thus, we can lock into the _nested-name-specifier_ interpretation and do the second lookup without having to know whether the _simple-template-id_ will be followed by `::` yet. List of files: /llvm-project/libcxx/include/regex

e2c2ffbe7a1b5d9e32a2ce64279475b50c4cba5b - [libc++][NFC] Run clang-format on libcxx/include again (#95874)

Tue, 18 Jun 2024 13:13:45 +0000

[libc++][NFC] Run clang-format on libcxx/include again (#95874)As time went by, a few files have become mis-formatted w.r.t. clang-format. This was made worse by the fact that formatting was not being enforced in extensionless headers. This commit simply brings all of libcxx/include in-line with clang-format again. We might have to do this from time to time as we update our clang-format version, but frankly this is really low effort now that we've formatted everything once. List of files: /llvm-project/libcxx/include/regex

cb417401879ce70b441a999c4a30f7b64b8d426b - [libc++] Refactor<__type_traits/is_swappable.h> (#86822)

Tue, 18 Jun 2024 09:01:43 +0000

[libc++] Refactor<__type_traits/is_swappable.h> (#86822)This changes the `is_swappable` implementation to use variable templates first and basing the class templates on that. This avoids instantiating them when the `_v` versions are used, which are generally less resource intensive. List of files: /llvm-project/libcxx/include/regex

bbe4a80605619dcb819ccfee016cf1355fb00af2 - [libc++] Enable modernize-use-equals-delete (#93293)

Tue, 18 Jun 2024 08:51:57 +0000

[libc++] Enable modernize-use-equals-delete (#93293)Differential Revision: https://reviews.llvm.org/D121213 List of files: /llvm-project/libcxx/include/regex

e9adcc488f96a9f2b8c4344f5e3c7ca6639b9562 - [libc++][regex] Correctly adjust match prefix for zero-length matches. (#94550)

Fri, 07 Jun 2024 15:15:02 +0000

[libc++][regex] Correctly adjust match prefix for zero-length matches. (#94550)For regex patterns that produce zero-length matches, there is one (imaginary) match in-between every character in the sequence being searched (as well as before the first character and after the last character). It's easiest to demonstrate using replacement: `std::regex_replace("abc"s, "!", "")` should produce `!a!b!c!`, where each exclamation mark makes a zero-length match visible. Currently our implementation doesn't correctly set the prefix of each zero-length match, "swallowing" the characters separating the imaginary matches -- e.g. when going through zero-length matches within `abc`, the corresponding prefixes should be `{'', 'a', 'b', 'c'}`, but before this patch they will all be empty (`{'', '', '', ''}`). This happens in the implementation of `regex_iterator::operator++`. Note that the Standard spells out quite explicitly that the prefix might need to be adjusted when dealing with zero-length matches in [`re.regiter.incr`](http://eel.is/c++draft/re.regiter.incr): > In all cases in which the call to `regex_search` returns `true`, `match.prefix().first` shall be equal to the previous value of `match[0].second`... It is unspecified how the implementation makes these adjustments. [Reproduction example](https://godbolt.org/z/8ve6G3dav) ```cpp #include #include #include int main() { std::string str = "abc"; std::regex empty_matching_pattern(""); { // The underlying problem is that `regex_iterator::operator++` doesn't update // the prefix correctly. std::sregex_iterator i(str.begin(), str.end(), empty_matching_pattern), e; std::cout << "\""; for (; i != e; ++i) { const std::ssub_match& prefix = i->prefix(); std::cout << prefix.str(); } std::cout << "\"\n"; // Before the patch: "" // After the patch: "abc" } { // `regex_replace` makes the problem very visible. std::string replaced = std::regex_replace(str, empty_matching_pattern, "!"); std::cout << "\"" << replaced << "\"\n"; // Before the patch: "!!!!" // After the patch: "!a!b!c!" } } ``` Fixes #64451 rdar://119912002 List of files: /llvm-project/libcxx/include/regex

04f01a2b9cedc291fa7dd941de841dc957c75a33 - [libc++] Make the availability header a sub-header of config (#93083)

Wed, 29 May 2024 01:29:11 +0000

[libc++] Make the __availability header a sub-header of __config (#93083)In essence, this header has always been related to configuration of the library but we didn't want to put it inside <__config> due to complexity reasons. Now that we have sub-headers in <__config>, we can move <__availability> to it and stop including it everywhere since we already obtain the required macros via <__config>. List of files: /llvm-project/libcxx/include/regex

83bc7b57714dc2f6b33c188f2b95a0025468ba51 - [libc++] Remove _LIBCPP_DISABLE_NODISCARD_EXTENSIONS and refactor the tests (#87094)

Mon, 22 Apr 2024 20:13:58 +0000

[libc++] Remove _LIBCPP_DISABLE_NODISCARD_EXTENSIONS and refactor the tests (#87094)This also adds a few tests that were missing. List of files: /llvm-project/libcxx/include/regex

37dca605c9bd41732da010ee97ed15ad9585a37d - [libc++] Clean up includes of <__assert> (#80091)

Thu, 29 Feb 2024 15:12:22 +0000

[libc++] Clean up includes of <__assert> (#80091)Originally, we used __libcpp_verbose_abort to handle assertion failures. That function was declared from all public headers. Since we don't use that mechanism anymore, we don't need to declare __libcpp_verbose_abort from all public headers, and we can clean up a lot of unnecessary includes. This patch also moves the definition of the various assertion categories to the <__assert> header, since we now rely on regular IWYU for these assertion macros. rdar://105510916 List of files: /llvm-project/libcxx/include/regex