Re: [PATCH] D31022: Implement P0298R3: `std::byte`

On 5 July 2017 at 14:29, James Y Knight wrote: > I actually didn't know that attribute existed. It does look like the right > thing to use here. However, unfortunately, it appears it doesn't work for > enum class in clang [[1]]. It *does* seem to work in GCC. > >

Re: [PATCH] D31022: Implement P0298R3: `std::byte`

I actually didn't know that attribute existed. It does look like the right thing to use here. However, unfortunately, it appears it doesn't work for enum class in clang [[1]]. It *does* seem to work in GCC. Unfortunately, it seems that GCC has actually hardcoded the type name "std::byte" (in

Re: [PATCH] D31022: Implement P0298R3: `std::byte`

FWIW, doesn't this just need a may_alias attribute on the definition? On Wed, Jul 5, 2017 at 2:39 PM James Y Knight via Phabricator via cfe-commits wrote: > jyknight added a comment. > > Ping. I don't think this got resolved, and I really wouldn't like to see >

[PATCH] D31022: Implement P0298R3: `std::byte`

jyknight added a comment. Ping. I don't think this got resolved, and I really wouldn't like to see released in this state...can you either revert this from the library, or implement the compiler support, before the 5.0 release branch? In https://reviews.llvm.org/D31022#716702, @jyknight

[PATCH] D31022: Implement P0298R3: `std::byte`

jyknight added a comment. I believe this needs compiler support, too, in order to treat namespace std { enum class byte : unsigned char {}; } as directly having tbaa type "omnipotent char" instead of a subtype. That is, given: void foo(char* x, int *y) { x[1] = char(y[0] & 0xff);

[PATCH] D31022: Implement P0298R3: `std::byte`

mehdi_amini added inline comments. Comment at: test/std/language.support/support.types/byteops/xor.assign.pass.cpp:13 + +// XFAIL: c++98, c++03, c++11, c++14 + EricWF wrote: > Nit. These should be `// UNSUPPORTED`. `XFAIL` is for bugs we need to fix. I have

[PATCH] D31022: Implement P0298R3: `std::byte`

mclow.lists closed this revision. mclow.lists added a comment. Committed as revision 298689 https://reviews.llvm.org/D31022 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D31022: Implement P0298R3: `std::byte`

EricWF added inline comments. Comment at: test/std/language.support/support.types/byteops/xor.assign.pass.cpp:13 + +// XFAIL: c++98, c++03, c++11, c++14 + Nit. These should be `// UNSUPPORTED`. `XFAIL` is for bugs we need to fix.

[PATCH] D31022: Implement P0298R3: `std::byte`

EricWF accepted this revision. EricWF added a comment. This revision is now accepted and ready to land. I still think we can come up with a better include structure, but we have plenty of time to figure that out before the next release. I see no reason to hold this up. @mclow.lists is there a

[PATCH] D31022: Implement P0298R3: `std::byte`

EricWF added a comment. I really dislike the circular dependencies between `` and ``. I suspect we can avoid this by only including `` in ``, which would allow `` to depend on ``. @mclow.lists Does that sound good to you? https://reviews.llvm.org/D31022

[PATCH] D31022: Implement P0298R3: `std::byte`

mclow.lists updated this revision to Diff 92370. mclow.lists added a comment. Put the `std::byte` type in the unadorned namespace `std`, rather than the versioned one. This matches the behavior of other types that the compiler "knows about", like `initializer_list`, `type_info`, `bad_alloc`

[PATCH] D31022: Implement P0298R3: `std::byte`

mclow.lists added inline comments. Comment at: www/cxx1z_status.html:144 http://wg21.link/P0521R0;>P0521R0LWGProposed Resolution for CA 14 (shared_ptr use_count/unique)IssaquahNothing to don/a + http://wg21.link/P0156R2;>P0156R2LWGVariadic Lock

[PATCH] D31022: Implement P0298R3: `std::byte`

mclow.lists created this revision. Implement `std::byte` from the paper http://wg21.link/P0298R3. Split the implementation across two files; putting the stuff that needs `enable_if` into and the rest in , where it belongs. Sadly, this means that now includes (at the end).