> On Jan 4, 2018, at 8:29 PM, David Zarzycki <d...@znu.io> wrote:
> 
> Hi Adrian,
> 
> Feel free to file a bug if you’re motivated. Personally speaking, I don’t 
> expect this bug to be on anybody’s priority list. The workaround of using 
> named structs/unions has no downside for most projects, and Swift is no 
> exception.

Filed as https://bugs.llvm.org/show_bug.cgi?id=35832 
<https://bugs.llvm.org/show_bug.cgi?id=35832>

John.

> 
> Dave
> 
> -- 
> Sent from my iPad
> 
>> On Jan 4, 2018, at 20:11, Adrian Prantl <apra...@apple.com> wrote:
>> 
>> 
>> 
>>>> On Dec 16, 2017, at 10:31 AM, John McCall via swift-dev 
>>>> <swift-dev@swift.org> wrote:
>>>> 
>>>> 
>>>> On Dec 16, 2017, at 9:08 AM, David Zarzycki via swift-dev 
>>>> <swift-dev@swift.org> wrote:
>>>> 
>>>> Hello,
>>>> 
>>>> I’m trying to improve SILNode memory layout density by adopting the AST 
>>>> bitfield macros. Unfortunately, multiple inheritance doesn’t seem to get 
>>>> along with anonymous/unnamed unions. Here is a distillation of the problem:
>>>> 
>>>> class B {
>>>> protected:
>>>> int i;
>>>> union { int j; };
>>>> };
>>>> 
>>>> class X : public B { };
>>>> class Y : public B { };
>>>> 
>>>> class Z : public X, public Y {
>>>> int a() { return X::i; } // works
>>>> int b() { return X::j; } // fails
>>>> };
>>>> 
>>>> Is this expected C++ behavior? I can certainly workaround this by naming 
>>>> the unnamed union, but before I do, I thought that I should check here 
>>>> first.
>>> 
>>> This seems like a bug; anonymous unions are just supposed to inject their 
>>> member names into the containing scope as if there was an ordinary member 
>>> there, and the explicit scope-qualification should resolve which subobject 
>>> is meant for such injected names the same it resolves them for ordinary 
>>> fields.  But if it's a bug in all existing clangs, it's a bug we're going 
>>> to have to work around.
>> 
>> Which should not prevent Dave from still reporting it on 
>> https://bugs.llvm.org/enter_bug.cgi?product=clang :-)
>> 
>> -- adrian
> 

_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Reply via email to