Thanks for your pull request, @WalterBright!

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub run digger -- build "master + dmd#21625"

So, we cannot pull this because of dlang/dlang.org#4276 which cannot be pulled because of this PR.

How about pull this one and then the other one?

I think we agreed in a monthly meeting that once the DIP gets accepted, the bugs should be fixed. Otherwise people start depending on broken behavior, or complain about yet another halfbaked D feature being released too early.

#18247
#20365
#20473
(There's also missing/incorrect debug info, and bitfields aren't printed correctly by writeln, which haven't been filed as issues yet)

Added label Feature: bitfields and tagged those three issues.

I think we agreed in a monthly meeting that once the DIP gets accepted, the bugs should be fixed. Otherwise people start depending on broken behavior, or complain about yet another halfbaked D feature being released too early.

#18247
#20365
#20473
(There's also missing/incorrect debug info, and bitfields aren't printed correctly by writeln, which haven't been filed as issues yet)

Only #18247 and maybe debug is for @WalterBright to look into.

Wrt dwarf debug, bit fields typically require the use of the DW_AT_data_bit_offset and DW_AT_bit_size attributes.

struct
{ align (1):
    int f1 : 1;
    int f2 : 32;
    int f3 : 4;
    int f4 : 2;
}

10$: DW_TAG_base_type
    DW_AT_name("int")
    DW_AT_byte_size(4)
    DW_AT_encoding(DW_ATE_signed)
...
DW_TAG_member
    DW_AT_name("f1")
    DW_AT_type(reference to 10$)
    DW_AT_data_bit_offset(0)
    DW_AT_bit_size(1)
DW_TAG_member
    DW_AT_name("f2")
    DW_AT_type(reference to 10$)
    DW_AT_data_bit_offset(1)
    DW_AT_bit_size(32)
DW_TAG_member
    DW_AT_name("f3")
    DW_AT_type(reference to 10$)
    DW_AT_data_bit_offset(33)
    DW_AT_bit_size(4)
DW_TAG_member
    DW_AT_name("f4")
    DW_AT_type(reference to 10$)
    DW_AT_data_bit_offset(37)
    DW_AT_bit_size(2)

That should be clear enough example for anyone to have a crack at.

#18247 has been fixed.

#20473 is fixed

I have a wip patch for the last linked issue that makes bit-fields return false from isLvalue (modifiableLvalue still needs to be true) - just need to fixup some errors so that bit-field is referred to instead of rvalue.

Raised/found a few more open bugs.

#18101
#18238
#21660 (fixed in #21661)
#21663
dlang/phobos#10840

What's the current holdup?

What's the current holdup?

Possibly just library support.

@ibuclaw can you please turn your code changes to writeln to a PR?

@ibuclaw can you please turn your code changes to writeln to a PR?

It doesn't handle bitfields properly though - bitfields can overlap other bitfields or even regular fields - someone with a bit more familiarity with why it formats the way it does should have a look in.

There are other issues with the formatter which has nothing to do with bitfields, but is adjacent to supporting wrt determining offsets and overlaps within a struct. dlang/phobos#10844

It would be best to put format support on the back burner.

FYI @dkorpel

Need to update frontend.h

         allInst(),
-        bitfields(),
+        bitfields(true),
         cplusplus((CppStdRevision)201103u),
         help(),
         v(),

lets discuss this at dconf

With the merging of dlang/phobos#10851 this is ready to pull.

Still dealing with support for packed and bitfields. The tl;dr of that is alignment is a bit of a mess, there's one AlignDeclaration node, but at least three different semantics and interactions with the packed attribute/declspec.

The current bitfield implementation does not support the "packed" gcc and vc semantics, where the bitfield can straddle two memory units. The behavior of it is different between gcc and vc. I view this as a niche extension, and should not impair pulling this PR.

@ibuclaw I am looking forward to your PR on packed bitfields! Thank you!