Page MenuHomePhabricator

georgthegreat (Yuriy Chernyshov)
User

Projects

User does not belong to any projects.

User Details

User Since
May 4 2020, 6:10 AM (48 w, 6 d)

Recent Activity

Mar 3 2021

georgthegreat abandoned D96786: Including <ciso646> should result in an #error since C++17.
Mar 3 2021, 2:26 AM · Restricted Project
georgthegreat added a comment to D96786: Including <ciso646> should result in an #error since C++17.

Ok, I am discarding this PR for the time being.

Mar 3 2021, 2:26 AM · Restricted Project

Mar 2 2021

georgthegreat added a comment to D96786: Including <ciso646> should result in an #error since C++17.

Ok, I have run CI check on a large codebase too.

Mar 2 2021, 12:24 AM · Restricted Project

Mar 1 2021

georgthegreat updated the diff for D96786: Including <ciso646> should result in an #error since C++17.

I have implemented similar patch in all headers mentioned in C++ working draft as reserved / removed.

Mar 1 2021, 11:04 AM · Restricted Project
georgthegreat updated the summary of D96786: Including <ciso646> should result in an #error since C++17.
Mar 1 2021, 8:44 AM · Restricted Project
georgthegreat added a comment to D96786: Including <ciso646> should result in an #error since C++17.

NB: At the time <ciso646> already causes trouble. People are expecting it to behave just like <iso646.h>. This works for most of the headers — you can replace <string.h> with <cstring> and get string.h transitively included, but does not work with this one.

Mar 1 2021, 8:43 AM · Restricted Project

Feb 28 2021

georgthegreat added a comment to D96786: Including <ciso646> should result in an #error since C++17.

@ldionne, I have changed the behavior to cause an error if the user includes <ciso646> expecting certain behavior from the standard library.

Feb 28 2021, 9:20 AM · Restricted Project
georgthegreat updated the diff for D96786: Including <ciso646> should result in an #error since C++17.
Feb 28 2021, 9:16 AM · Restricted Project

Feb 16 2021

georgthegreat added a comment to D96786: Including <ciso646> should result in an #error since C++17.

MSVC only recognizes the alternative tokens in strict (/permissive-) mode to avoid breaking legacy code that uses those lexemes as identifiers. I have no opinion on whether or not libc++ should accept this change, but I strongly recommend that C++ code that wants portable conformant behavior when compiling with MSVC should use /permissive-, which will finally be on-by-default in C++20 mode.

Feb 16 2021, 10:24 AM · Restricted Project
georgthegreat added a comment to D96786: Including <ciso646> should result in an #error since C++17.

@ldionne, actually, I was talking about standard-bound #error, as follows:

Feb 16 2021, 10:21 AM · Restricted Project
georgthegreat added a comment to D96786: Including <ciso646> should result in an #error since C++17.

I have digged through C++ Working Draft and found the following:

Feb 16 2021, 10:07 AM · Restricted Project
georgthegreat requested review of D96786: Including <ciso646> should result in an #error since C++17.
Feb 16 2021, 6:59 AM · Restricted Project

Dec 5 2020

georgthegreat added a comment to D92325: Add std::hash<char8_t> specialization if char8_t is enabled.

The final revision is buildable and can be merged.
@ldionne, could you merge it?

Dec 5 2020, 2:42 AM · Restricted Project
georgthegreat updated the diff for D92325: Add std::hash<char8_t> specialization if char8_t is enabled.

The attempt to test std::hash via _gnu_cxx was just wrong.
I can not find any place to put individual hash tests anywhere, so I am removing the test completely.

Dec 5 2020, 1:25 AM · Restricted Project

Dec 3 2020

georgthegreat added a comment to D92212: Make libcxx work according to Clang C++ Status if -fchar8_t is passed.

Ok, I got you point.
I would not use this approach for migration though.

Dec 3 2020, 11:45 AM · Restricted Project
georgthegreat updated the diff for D92325: Add std::hash<char8_t> specialization if char8_t is enabled.
Dec 3 2020, 11:30 AM · Restricted Project
georgthegreat added a comment to D92212: Make libcxx work according to Clang C++ Status if -fchar8_t is passed.

Should not we remove || !defined(__cpp_char8_t) part of LIBCPP_NO_HAS_CHAR8_T then?
This looks like an attempt to support compilation with -std=c++20 -fnochar8_t which is the most weird mode ever (and it is not tested via CI)

Dec 3 2020, 11:20 AM · Restricted Project
georgthegreat added a comment to D92212: Make libcxx work according to Clang C++ Status if -fchar8_t is passed.

btw, I am ok to limit this behavior to -std=c++17. Condition in <version> might be changed as follows:

Dec 3 2020, 12:48 AM · Restricted Project

Dec 2 2020

georgthegreat added a comment to D92212: Make libcxx work according to Clang C++ Status if -fchar8_t is passed.

I think it's fairly important for us to decide which way we're taking the project, since similar questions will happen in the future. We're not only having a discussion about char8_t here, we're having a design discussion about how to handle feature test macros defined by the compiler.

Dec 2 2020, 5:56 AM · Restricted Project
georgthegreat added a comment to D92212: Make libcxx work according to Clang C++ Status if -fchar8_t is passed.

Did you try something like what https://stackoverflow.com/a/56833374/627587 suggests?

Dec 2 2020, 5:55 AM · Restricted Project

Dec 1 2020

georgthegreat planned changes to D92325: Add std::hash<char8_t> specialization if char8_t is enabled.

I am waiting for D92212 to land, then I will rebase the diff to make it consistent with the changes proposed by @ldionne.

Dec 1 2020, 12:49 PM · Restricted Project
georgthegreat accepted D92212: Make libcxx work according to Clang C++ Status if -fchar8_t is passed.

You iterate locally, fixing issues and committing them until the whole code base compiles both as C++17 and C++20.

Dec 1 2020, 12:44 PM · Restricted Project
georgthegreat added inline comments to D92325: Add std::hash<char8_t> specialization if char8_t is enabled.
Dec 1 2020, 2:13 AM · Restricted Project
georgthegreat updated the diff for D92212: Make libcxx work according to Clang C++ Status if -fchar8_t is passed.

Just fix the logical expression without introducing radical changes to libc++ logic

Dec 1 2020, 2:12 AM · Restricted Project
georgthegreat updated the diff for D92325: Add std::hash<char8_t> specialization if char8_t is enabled.

Use libc++-specific macro to rest if hashing should be enabled.

Dec 1 2020, 2:10 AM · Restricted Project

Nov 30 2020

georgthegreat added a comment to D92212: Make libcxx work according to Clang C++ Status if -fchar8_t is passed.

As for the 2, I can not understand why libcxx should have any logic depending on the compiler feature support. Could you elaborate / invent artificial scenario when such logic is necessary?

Nov 30 2020, 11:22 AM · Restricted Project
georgthegreat added a comment to D92212: Make libcxx work according to Clang C++ Status if -fchar8_t is passed.
  1. My thoughts are quite different. This macro requires double negation upon usage: #ifndef _LIBCPP_NO_HAS_CHAR8_T. I personally find troubles reading any negation. #ifdef __cpp_char8_t is much shorter and easier to understand. And it is standartized!
Nov 30 2020, 11:19 AM · Restricted Project
georgthegreat added a comment to D92325: Add std::hash<char8_t> specialization if char8_t is enabled.

There is a chance that _LIBCPP_NO_HAS_CHAR8_T should be removed in the course of https://reviews.llvm.org/D92212

Nov 30 2020, 8:19 AM · Restricted Project
georgthegreat added reviewers for D92325: Add std::hash<char8_t> specialization if char8_t is enabled: ldionne, mclow.lists.
Nov 30 2020, 7:48 AM · Restricted Project
georgthegreat requested review of D92325: Add std::hash<char8_t> specialization if char8_t is enabled.
Nov 30 2020, 7:45 AM · Restricted Project

Nov 29 2020

georgthegreat requested review of D92212: Make libcxx work according to Clang C++ Status if -fchar8_t is passed.
Nov 29 2020, 10:22 AM · Restricted Project

Nov 28 2020

georgthegreat added a comment to D92212: Make libcxx work according to Clang C++ Status if -fchar8_t is passed.

Found the official explanation and motivation regarding the feature testing macros.

Nov 28 2020, 4:03 AM · Restricted Project
georgthegreat added a comment to D92212: Make libcxx work according to Clang C++ Status if -fchar8_t is passed.

NB: in the frontend world of javascript / css, a similar technique, codenamed as feature detection is widely used.
See, e. g.:

Nov 28 2020, 2:19 AM · Restricted Project
georgthegreat added a comment to D92212: Make libcxx work according to Clang C++ Status if -fchar8_t is passed.

@ldionne, this PR appeared as a part of a large monorepo migration to a new standard.
If I just change -std=c++17 to -std=c++20, thousands of new errors appear (even upon switching off all the major deprecation warnings), so I am trying to split the switch into smaller parts and fix them one by one.
New standard changes behavior of u8"" literals in an incompatible way, so I have to remove these literals from the codebase and prevent new std::string = u8"blah" lines from appearance.

Nov 28 2020, 2:15 AM · Restricted Project

Nov 27 2020

georgthegreat added a comment to D92212: Make libcxx work according to Clang C++ Status if -fchar8_t is passed.

Another thing to consider is that -fchar8_t changes the behavior of u8"" literals, hence they can no longer be assigned to old good std::string-types.
At the time libcxx provides no alternative.

Nov 27 2020, 4:13 AM · Restricted Project
georgthegreat updated the summary of D92212: Make libcxx work according to Clang C++ Status if -fchar8_t is passed.
Nov 27 2020, 1:52 AM · Restricted Project
georgthegreat retitled D92212: Make libcxx work according to Clang C++ Status if -fchar8_t is passed from Make libcxx work according to clang user manual if -fchar8_t is passed to Make libcxx work according to Clang C++ Status if -fchar8_t is passed.
Nov 27 2020, 12:56 AM · Restricted Project
georgthegreat retitled D92212: Make libcxx work according to Clang C++ Status if -fchar8_t is passed from Make libcxx work as expected with -fchar8_t to Make libcxx work according to clang user manual if -fchar8_t is passed.
Nov 27 2020, 12:44 AM · Restricted Project
georgthegreat added inline comments to D92212: Make libcxx work according to Clang C++ Status if -fchar8_t is passed.
Nov 27 2020, 12:42 AM · Restricted Project
georgthegreat requested review of D92212: Make libcxx work according to Clang C++ Status if -fchar8_t is passed.
Nov 27 2020, 12:40 AM · Restricted Project

Nov 5 2020

georgthegreat added a comment to D87697: Do not construct std::string from nullptr.

@dblaikie, so, could you, please, commit this at last?

Nov 5 2020, 11:42 AM · Restricted Project
georgthegreat added a reviewer for D87697: Do not construct std::string from nullptr: dblaikie.
Nov 5 2020, 1:17 AM · Restricted Project
georgthegreat updated the diff for D87697: Do not construct std::string from nullptr.

Changed as dblaikie@ suggested. Not all the types are handled during the switch, so default is still required in order to prevent compiler from issuing warnings.

Nov 5 2020, 1:17 AM · Restricted Project

Nov 3 2020

georgthegreat added a comment to D87697: Do not construct std::string from nullptr.

So, could someone, please, commit this PR? I have no write access to llvm.

Nov 3 2020, 5:47 AM · Restricted Project
georgthegreat updated the diff for D87697: Do not construct std::string from nullptr.

Restore unreachable return statement, upon mclow.lists@ request.

Nov 3 2020, 3:09 AM · Restricted Project

Sep 26 2020

georgthegreat added inline comments to D87697: Do not construct std::string from nullptr.
Sep 26 2020, 2:57 AM · Restricted Project

Sep 15 2020

georgthegreat updated the diff for D87697: Do not construct std::string from nullptr.
Sep 15 2020, 8:03 AM · Restricted Project
georgthegreat requested review of D87697: Do not construct std::string from nullptr.
Sep 15 2020, 7:49 AM · Restricted Project

Sep 6 2020

georgthegreat added a comment to D87185: Do not construct string from nullptr.

I have no commit access to llvm monorepo, so could, please, someone land this commit?

Sep 6 2020, 2:26 PM · Restricted Project
georgthegreat accepted D87185: Do not construct string from nullptr.
Sep 6 2020, 2:24 PM · Restricted Project

Sep 5 2020

georgthegreat updated the summary of D87185: Do not construct string from nullptr.
Sep 5 2020, 7:55 AM · Restricted Project
georgthegreat updated the summary of D87185: Do not construct string from nullptr.
Sep 5 2020, 3:57 AM · Restricted Project
georgthegreat updated the summary of D87185: Do not construct string from nullptr.
Sep 5 2020, 3:17 AM · Restricted Project
georgthegreat added reviewers for D87185: Do not construct string from nullptr: nikic, mclow.lists.
Sep 5 2020, 3:16 AM · Restricted Project
georgthegreat requested review of D87185: Do not construct string from nullptr.
Sep 5 2020, 3:13 AM · Restricted Project

May 18 2020

georgthegreat added a comment to D79427: [libcxx] Explicitly mark erroneous string_view ctors as deleted.

I have just submitted P2166R0 to LEWG-I, LEWG, LWG.
While the proposal is not published, this link can be used to preview it.

May 18 2020, 9:07 AM

May 6 2020

georgthegreat added a comment to D79427: [libcxx] Explicitly mark erroneous string_view ctors as deleted.

If you know that the size of your data is always zero, you should use default ctor, shouldn't you?

May 6 2020, 8:02 AM
georgthegreat added a comment to D79427: [libcxx] Explicitly mark erroneous string_view ctors as deleted.

Indeed, the proposed change does not allow to get rid of runtime checks — it just makes invalid cases easier to detect.
As for the rarity, I have applied these changes (both to std::string_view and std::string) and ran CI checks over a private monorepo.
It gave me 7 possible problematic places, one of which would actually lead to a segfault, if reached in runtime (the code was actually reachable). Most of the problems are caused by contrib code, including projects like

May 6 2020, 1:02 AM

May 5 2020

georgthegreat updated the summary of D79427: [libcxx] Explicitly mark erroneous string_view ctors as deleted.
May 5 2020, 10:14 AM
georgthegreat updated the summary of D79427: [libcxx] Explicitly mark erroneous string_view ctors as deleted.
May 5 2020, 9:41 AM
georgthegreat created D79427: [libcxx] Explicitly mark erroneous string_view ctors as deleted.
May 5 2020, 9:41 AM