[swift-dev] SILNode versus C++

[John McCall]

> On Jan 4, 2018, at 8:29 PM, David Zarzycki <dave at 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 <aprantl at apple.com> wrote:
>> 
>> 
>> 
>>>> On Dec 16, 2017, at 10:31 AM, John McCall via swift-dev <swift-dev at swift.org> wrote:
>>>> 
>>>> 
>>>> On Dec 16, 2017, at 9:08 AM, David Zarzycki via swift-dev <swift-dev at 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
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20180104/8f0a3dec/attachment.html>