This reverts 4d10c1165442cbbbc0017b48fcdd7dae1ccf3678 and its two
dependent commits: e6b9805b574bb5c90263ec7fbcb94df76d2807a4 and
c243406a695ca056a07ef4064b0f9feee7685320, see discussion in
https://github.com/llvm/llvm-project/pull/165598#issuecomment-3563825509.

Depends on:
* https://github.com/llvm/llvm-project/pull/168382

As of recent, LLVM includes the bit-size as a `DW_AT_bit_size` (and as
part of `DW_AT_name`) of `_BitInt`s in DWARF. This allows us to mark
`_BitInt`s as "reconstitutable" when compiling with
`-gsimple-template-names`. We still only omit template parameters that
are `<= 64` bit wide. So support `_BitInt`s larger than 64 bits is not
part of this patch.

MSVC supports an extension allowing to delete an array of objects via
pointer whose static type doesn't match its dynamic type. This is done
via generation of special destructors - vector deleting destructors.
MSVC's virtual tables always contain a pointer to the vector deleting
destructor for classes with virtual destructors, so not having this
extension implemented causes clang to generate code that is not
compatible with the code generated by MSVC, because clang always puts a
pointer to a scalar deleting destructor to the vtable. As a bonus the
deletion of an array of polymorphic object will work just like it does
with MSVC - no memory leaks and correct destructors are called.

This patch will cause clang to emit code that is compatible with code
produced by MSVC but not compatible with code produced with clang of
older versions, so the new behavior can be disabled via passing
-fclang-abi-compat=21 (or lower).

This is yet another attempt to land vector deleting destructors support
originally implemented by
https://github.com/llvm/llvm-project/pull/133451.

This PR contains fixes for issues reported in the original PR as well as
fixes for issues related to operator delete[] search reported in several
issues like

https://github.com/llvm/llvm-project/pull/133950#issuecomment-2787510484
https://github.com/llvm/llvm-project/issues/134265

Fixes https://github.com/llvm/llvm-project/issues/19772

`DISubprogram`s are attached to call sites to support various debug info
features, including entry values and tail calls. Clang 9.0
(0f6516856670a435461f56a9faeb4aa8a35a6679) was the first version to
include this kind of call site `DISubprogram` attachment.

This earlier work appears to visit only some call site variants,
however. The call site attachment was added to a higher-level `EmitCall`
path in Clang's code gen that is only used by some call variants. In
particular, some C++ member calls use a different code gen path, which
did not include this call site attachment step, and thus the debug info
it triggers (e.g. call site entries) was not emitted for such calls.

This moves `DISubprogram` attachment to a lower-level call emission path
that is used by all call variants.

Fixes https://github.com/llvm/llvm-project/issues/161962

To improve debuggability, the macro arguments should be resolved to
their original location rather than macro expansion location.

[PR in
cation](https://github.com/user-attachments/assets/994fb89f-83be-4c21-a79c-f8e51d818f7b)

fixes #160667

Follow on from #164372 

This changes the DW_AT_name for `_BitInt(N)` from `_BitInt` to `_BitInt(N)`

DW_TAG_base_type DIEs are permitted to have both byte_size and bit_size
attributes "If the value of an object of the given type does not fully
occupy the storage described by a byte size attribute"

* Add DataSizeInBits to DIBasicType (`DIBasicType(... dataSize: n ...)` in IR).
* Change Clang to add DataSizeInBits to _BitInt type metadata.
* Change LLVM to add DW_AT_bit_size to base_type DIEs that have non-zero
  DataSizeInBits.

TODO: Do we need to emit DW_AT_data_bit_offset for big endian targets?
See discussion on the PR.

Fixes [#61952](https://github.com/llvm/llvm-project/issues/61952)

---------

Co-authored-by: David Stenberg <david.stenberg@ericsson.com>

In the past we used to only mark variables artificial that were
`isImplicit`. We would also omit the location information if the
variable's parent was implicit. Since
https://github.com/llvm/llvm-project/pull/100355 we made the logic to
mark variables as artificial the same as determining whether to omit its
location or not. This was to support binding variable declarations,
which we would like to have line information for (and don't want to mark
artificial as they are explicitly named in source).

However, this doesn't quite do the expected for parameters of
Objective-C synthesised property accessors. An Objective-C setter will
have an explicit parameter, which is the ivar to write to. However,
because the parent (i.e., the synthesised method) is artificial, we now
mark that parameter artificial. This is example debug-info for such an
accessor:
```
0x00000118:   DW_TAG_subprogram                                                                           
                DW_AT_low_pc    (0x0000000000000044)
                DW_AT_high_pc   (0x0000000000000078)
                DW_AT_frame_base        (DW_OP_reg29 W29)   
                DW_AT_object_pointer    (0x00000128)
                DW_AT_specification     (0x00000068 "-[Foo setFooProp:]")
                                                     
0x00000128:     DW_TAG_formal_parameter
                  DW_AT_location        (DW_OP_fbreg -8)
                  DW_AT_name    ("self")                                                                  
                  DW_AT_type    (0x00000186 "Foo *")
                  DW_AT_artificial      (true)    
                                                     
0x00000131:     DW_TAG_formal_parameter
                  DW_AT_location        (DW_OP_breg31 WSP+16)
                  DW_AT_name    ("_cmd")
                  DW_AT_type    (0x0000018b "SEL")
                  DW_AT_artificial      (true)      
                                                     
0x0000013a:     DW_TAG_formal_parameter                                                                   
                  DW_AT_location        (DW_OP_breg31 WSP+8)
                  DW_AT_name    ("fooProp")                                                               
                  DW_AT_type    (0x000000aa "id")
                  DW_AT_artificial      (true)    
```

Note how the `fooProp` parameter is marked artificial, although it
technically is an explicitly passed parameter. We want to treat the
synthesised method like any other, where explicitly passed parameters
aren't artificial. But we do want to omit the file/line info because it
doesn't exist in the source.

This patch prevents such parameters from being marked artificial. We
could probably generalise this to any kind of synthesised method, not
just Objective-C. But I'm currently not aware of such synthesised
functions, so made it Objective-C specific for now for testability.

*Motivator*
Marking such parameters artificial makes LLDB fail to parse the ObjC
method and emit an error such as:
```
error: Foo.o [0x00000000000009d7]: invalid Objective-C method DW_TAG_subprogram (DW_TAG_subprogram), please file a bug and attach the file at the start of this error message
```

rdar://163063569

Depends on:
* https://github.com/llvm/llvm-project/pull/163348
* https://github.com/llvm/llvm-project/pull/162632

With this patch Clang will start emitting `DW_AT_language_{name,
version}` for C++/C/Objective-C/Objective-C++ when using `-gdwarf-6`. We
adjust the `DISourceLanguageName` (which we pass to `DICompileUnit`) to
hold a `DW_AT_language_name_` and version code when in DWARFv6.
Otherwise we continue using the `DW_LANG_` version of
`DISourceLanguageName`.

We didn't back-port emitting
`DW_AT_language_name`/`DW_AT_language_version` to DWARFv5 (unlike GCC,
which emits both the new and old language attributes in DWARFv5) because
there wasn't a compelling reason to do so (yet).

This rename was made as part of
https://github.com/llvm/llvm-project/pull/147835 in order to ease
rebasing the PR, and give a nice window for other patches to get rebased
as well.

It has been a while already, so lets go ahead and rename it back.