Fix C++ type name collisions in xcpclient

[pamirmundt]

Summary

Fix C++ type collisions when generating A2L definitions from DWARF information.

DWARF type entries generally provide an unqualified DW_AT_name. Types with the same name in different C++ namespaces could therefore share an incorrect A2L typedef, causing instances to reference the wrong type definition.

Changes

• Qualify colliding type names using their namespace or enclosing type.
• Preserve existing short type names when they are unambiguous.
• Use the same qualified identifier for typedef definitions and instance references.
• Only perform the additional DWARF scope lookup when duplicate type names are detected.
• Document the qualified-name behavior.
• Add an ARM DWARF regression fixture covering:
  • Same-named types with different sizes.
  • Same-named, equal-sized types with different members.

Testing

• All existing and new tests pass: 12 passed, 0 failed.
• The regression test fails on the unchanged master branch and passes with this fix.

Fixes #125

[RainerZ]

Thanks for the precise report and for the pull request. Your analysis is right: DW_AT_name is the unqualified name, and the typedef has to be qualified with the enclosing namespaces or classes when the same name is used by different types.

I started in parallel to you with an AI supported analysis and fix of the problem.
The resulting xcpclient is now in my pull request V2.1.12 (RainerZ/XCPlite commit). I compared it to your very clean implementation and it uses exactly the same naming policy: scope-qualified names only for ambiguous type names, e.g. motor_control.Input and valve_control.Input, plain names otherwise. You should observe the same behaviour like yours.
Because my AI assistant discovered several related issue cases along the way, which your PR in its current form does not cover, I would like to keep my changes and close this PR:

• const/volatile qualified variables: the DWARF type of such a variable is a DW_TAG_const_type / DW_TAG_volatile_type entry without a name, which is not in the ambiguity map, so the plain name is used again and the collision comes back (verified with volatile motor_control::Input / valve_control::Input variables: one TYPEDEF_STRUCTURE Input and "Conflicting redefinition of typedef Input" warnings). volatile is what we recommend for measurable locals, so this matters in practice.
• Same-named types without a scope but with different content, e.g. file-local struct tags in two C files or anonymous namespaces: the qualified names are equal, nothing is renamed, and the second type silently gets the layout of the first. V2.1.12 compares the typedef content and appends a numeric suffix with a warning.
• Same-named variables in different namespaces (motor_control::input / valve_control::input): the second one is dropped with a duplicate instance error. They are now registered as motor_control.input / valve_control.input.
• GCC emits a namespace scope variable as a declaration plus a CU-level definition with DW_AT_specification; the pairs are merged now instead of producing duplicate instance errors.
• Metadata macros (XCP_COMMENT, XCP_UNIT, ...) inside a namespace have no DWARF location and a mangled internal-linkage symbol, so their address could not be resolved. V2.1.12 resolves it, and the macros can be used in the same namespace as the variable without a prefix.
• A struct used for a measurement and for a calibration parameter gets separate typedefs (TYPEDEF_MEASUREMENT vs. TYPEDEF_CHARACTERISTIC components).

Your fixture cpp_type_name_collisions.cpp is now part of the xcpclient unit tests, with credits, so your case stays covered.

There also is a new up to date documentation file on offline A2L generation.

I tested with the no_a2l library configuration in absolute addressing mode and the C++ no_a2l example on Linux, have no hardware with FreeRTOS at the moment.

I would be happy, if you could verify that the V2.1.14 xcpclient serves your needs in your project.

Thanks ...