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.
>
> Unfortunately, it seems that GCC
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 gcc/c
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
> released in this state...can you ei
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 wrote:
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);
x
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 mixe
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
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.
https://reviews.llvm.org/D3102
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 fe
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
___
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` and
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
guardK
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).
https://reviews.
13 matches
Mail list logo