Categorize some failing libcxx tests #5231
Conversation
| # We disagree on the syntax flags set by the default basic_regex constructor: we set 0, libc++ sets ECMAScript. | ||
| # Relates to LWG-3604. | ||
| std/re/re.regex/re.regex.construct/default.pass.cpp FAIL | ||
| std/re/re.regex/re.regex.nonmemb/re.regex.nmswap/swap.pass.cpp FAIL | ||
| std/re/re.regex/re.regex.swap/swap.pass.cpp FAIL | ||
|
|
There was a problem hiding this comment.
I'm not really sure where to put this one. The underlying issue is that [re.regex.construct]/1 does not specify the value returned by flags() as a postcondition on the default constructor, so MSVC STL returns 0 (which could be considered more in line with the postconditions on all the other constructors that require that flags() must return the flags passed to the constructor unchanged) while libc++ returns regex_constants::ECMAScript (which is probably informed by [re.synopt]/1's statement that the default grammar is ECMAScript if no other grammar is requested).
LWG-3604 is related, but discusses the postcondition on the flags imposed by all the other constructors and argues that they are too strict. Here, the problem is kind of the opposite: The standard doesn't state a postcondition on the flags for the default constructor at all.
There was a problem hiding this comment.
LWG-3604 does discuss this problem at the end:
Also, the constructors say "Postconditions: flags() returns f." This prevents an implementation from storing f|ECMAScript in flags() if no grammar element is present in f. This seems like an unnecessary restriction, and forces implementations to do extra work to check if the ECMAScript grammar is in use. Arguably, it would even be better to require implementations to set ECMAScript in flags() if no grammar element was set in the flags passed to the constructor. This problem was introduced by LWG 2330(i).
I agree that there's no obvious place for this one - "LIKELY BOGUS TESTS" seems as good as anything, since if the Standard is vague on what happens, the test shouldn't be expecting something specific. Good enough for me, and a vast improvement over the status quo of "not analyzed".
| # We disagree on the syntax flags set by the default basic_regex constructor: we set 0, libc++ sets ECMAScript. | ||
| # Relates to LWG-3604. | ||
| std/re/re.regex/re.regex.construct/default.pass.cpp FAIL | ||
| std/re/re.regex/re.regex.nonmemb/re.regex.nmswap/swap.pass.cpp FAIL | ||
| std/re/re.regex/re.regex.swap/swap.pass.cpp FAIL | ||
|
|
There was a problem hiding this comment.
LWG-3604 does discuss this problem at the end:
Also, the constructors say "Postconditions: flags() returns f." This prevents an implementation from storing f|ECMAScript in flags() if no grammar element is present in f. This seems like an unnecessary restriction, and forces implementations to do extra work to check if the ECMAScript grammar is in use. Arguably, it would even be better to require implementations to set ECMAScript in flags() if no grammar element was set in the flags passed to the constructor. This problem was introduced by LWG 2330(i).
I agree that there's no obvious place for this one - "LIKELY BOGUS TESTS" seems as good as anything, since if the Standard is vague on what happens, the test shouldn't be expecting something specific. Good enough for me, and a vast improvement over the status quo of "not analyzed".
|
Thanks, I love seeing progress on categorizing test failures!! 😻 |
|
I'm mirroring this to the MSVC-internal repo - please notify me if any further changes are pushed. |
📜 📄 📃 |
... which are mostly related to
<regex>.