[cDAC] Rename datadescriptor.h -> datadescriptor.inc

[max-charlamb]

Renames datadescriptor.h to datadescriptor.inl for upcoming PR allowing multiple contracts.

In the future datadescriptor.h will be included once for the actual #includes required by the datadescriptors and datadescriptor.inl will be included multiple times for processing.

[Copilot]

Pull Request Overview

This PR renames the header file datadescriptor.h to datadescriptor.inl as part of preparation for future work enabling multiple contracts. The change is purely a file rename with corresponding include statement updates.

• Updates all include statements from datadescriptor.h to datadescriptor.inl

[dotnet-policy-service]

Tagging subscribers to this area: @steveisok, @dotnet/dotnet-diag
See info in area-owners.md if you want to be subscribed.

[risc-vv]

@dotnet/samsung Could you please take a look? These changes may be related to riscv64.

[jkotas]

.inl extension is typically used for files that contain implementations of inline functions. datadescriptor.h/inl is not that. I am not sure whether this rename is an improvement.

[max-charlamb]

.inl extension is typically used for files that contain implementations of inline functions. datadescriptor.h/inl is not that. I am not sure whether this rename is an improvement.

I agree this isn't the best naming scheme. In order to reuse the datadescriptor mechanisms, I need to separate out the datadescriptor defines (which are imported multiple times) and the required includes.

Would you prefer keeping the datadescriptor defines in datadescriptor.h and having a separate header file for the includes?

[jkotas]

To highlight that the file included multiple times is not an ordinary header file, I would use .inc suffix. For example, we do it here. verifylayouts.inc is the file included multiple times in this case. ChatGPT agrees: https://chatgpt.com/share/6883ff8c-14d8-8012-8c3e-437942296c75

(We also have a few places where we just use .h that's mildly confusing. For example, we do that here and here. metasig.h is the file included multiple times in this case.)

[jkotas]

For stitching of multiple data contracts together (I assume that you need it for the GC), it may be useful to start with a spec edit (https://github.com/dotnet/runtime/blob/main/docs/design/datacontracts/datacontracts_design.md and linked docs) and agree on the details before you are done with the implementation.