Updated the test filename to reflect the change made in D93559.

Thanks a lot, Aditya. Again, my apologies for the screw-up. I will make sure I won't make the same mistake next time I add a new file.

In D93462#2463742, @gkm wrote:

@cchen15 @SouraVX @aprantl

This diff breaks git source trees on case-insensitive filesystems, such as on macOS.
I did this on Linux, which is case-sensitive:

$ find . |fgrep -i llvm/test/DebugInfo/X86/DIModule.ll
./llvm/test/DebugInfo/X86/DIModule.ll
./llvm/test/DebugInfo/X86/dimodule.ll

On a case-insensitive filesystem, these names collide and one overwrites the other, yeilding a tree with irreconcilable conflicts.

Please fix ASAP! Thanx!

Thanks for catching this for me. I don't work on Mac. :(

In D93462#2462118, @SouraVX wrote:

LGTM! Thanks for the patch.
One small thing, do you mind adding a one liner to release notes ? It would help in tracking extensions to Debug Metadata(previous extensions of DIModule were part of LLVM11).

Made changes based on the review comments.

Typed the attributes as PointerUnion<DIExpression *, DIVariable *>, and updated the test to exercise the DIVariable case.

In D89817#2353822, @aprantl wrote:

We can do that, but then the debugger would need to work a bit harder in order to get a constant, doesn't it? I don't feel strongly either way. If you do want it done the way you prefer, please let me know and I will make the change.

That's an interesting point. Do we emit different DWARF FORMs for constant vs constant DIExpression? An elegant solution would be to recognize constant DIExpressions in AsmPrinter (DIExpression::isConstant) and emit the same DWARF FORM we would emit for an IR constant if the expression is a constant.

Reverted back to type those attributes as Metadata to allow DIVairbale.

Also, DIBuilder::createConstantValueExpression(uint64_t) is already available for doing constant via DIExpression,, and its usage is demonstrated in the unit test.

Typed the attributes as DIExpression*, as suggested by @aprantl.

In D89817#2347933, @aprantl wrote:

These can be DIExpression, ConstantAsMetadata, etc, so Metadata looks to be the right specificity (and the underlying 'get' function it calls types them as Metadata too).

Why do we need to accept both DIExpression and ConstantAsMetadata? Since we can also represent all constants as DIExpression, I think I would prefer to have only one way to represent a constant. Would it be feasible to expect clients to pass constants as DIExpression(DW_OP_constu, <number>, DW_OP_stack_value)? And if it doesn't already exist perhaps add a DIExpression *DIBuilder::createConstantExpression(unsigned value) API?

Including the rank attribute in the patch.

Added a unit test for the patch.

Sorry. Please ignore Patch 2.

Per review comments, fixed/enhanced the description of createTypeArray.

Per review comments, fixed/enhanced the description of createArrayType.

Regarding test: Does the test idea laid out in my opening comment sound reasonable?

I'd appreciate some guidance on what test to add for this change. Would it be sufficient to have a unittest that calls createArrayType to create a DICompositeType, and then get the three new attributes back from the DICompositeType using the getRaw* functions to check that they match with the arguments to the createArrayType call? Thanks.