HIP ramifications: rename language_cplus to language_cplus_

[amd-shahab]

After the introduction of

63ebd1a gdb/language: add "is_cplus_dialect ()" check
8d269b6 gdb/language: add "strip_cplus_dialect ()"

that for the benefit of the HIP language, try to group C++-like
languages together, there can easily be an oversight when
upstream changes introduce new instances of language_cplus
into the code base. This patch renames the (downstream)
language_cplus, so that such new instances are caught by build
failures.

When the build fails, given the context, there are 3 possible
outcomes:

1. Using "is_cplus_dialect (...)" instead
2. Using "strip_cplus_dialect (...)", followed by a comparison
   against "language_cplus_" value
3. Renaming it to "language_cplus_"

After this point, any instance of "langauge_cplus_" indicates
that we have already examined the situation and it is supposed
to be that way.

The "language_cplus" instances in the comments are not touched
for two reasons:

1. Less amount of changes to avoid likely conflicts in the future
2. When we will go back upstream and have to undo this patch,
   there will be a few less things to take care of.

[lumachad]

Is upstreaming the HIP language support a reasonable alternative to avoid having such a workaround downstream?

[lancesix]

the __ in the middle looks like a typo (unless it is just not noticed), I'd probably prefer language_cplus_ so the trailing underscore looks more intentional.

[lancesix]

Is upstreaming the HIP language support a reasonable alternative to avoid having such a workaround downstream?

If what we have seems acceptable upstream, sure! It won't be exercised properly until we have debug info that goes with the said language, but maybe upstream can be ok with that.

[lancesix]

The change from "language_cplus" to "language__cplus" was preferred over something like "language_cplus_". Otherwise, the output of "git grep language_cplus" could be polluted.

Why would we really care of git grep? The point of the rename is to have the compiler do all the work and let us know if upstream introduces any use of language_cplus that needs to be converted downstream. grepping seems the wrong approach.

[amd-shahab]

Is upstreaming the HIP language support a reasonable alternative to avoid having such a workaround downstream?

upstreaming and this can happen next to each other. even if we begin the process of upstraming today, it can take a while before it gets in. meanwhile, we will have spent more time on trying to catch the new changes.

[amd-shahab]

The change from "language_cplus" to "language__cplus" was preferred over something like "language_cplus_". Otherwise, the output of "git grep language_cplus" could be polluted.

Why would we really care of git grep? The point of the rename is to have the compiler do all the work and let us know if upstream introduces any use of language_cplus that needs to be converted downstream. grepping seems the wrong approach.

for analysis purposes. nonetheless, it can be achieved with word markers (git grep 'language_cplus\>').

[amd-shahab]

• language__cplus -> language_cplus_.
• update the commit message to reflect that
• reword the commit message about build failures outcomes

[lancesix]

The commit message still says rename language_cplus to language__cplus), needs to be kept in sync with the content.

[simark]

the __ in the middle looks like a typo (unless it is just not noticed), I'd probably prefer language_cplus_ so the trailing underscore looks more intentional.

Also it's technically reserved to the language implementation:

https://devblogs.microsoft.com/oldnewthing/20230109-00/?p=107685

[amd-shahab]

• update the git commit title

[amd-shahab]

• more fixes in the commit message (language__cplus -> language_cplus_).

[lancesix]

Sorry I completely missed this one. This looks good to me, and inline with what we discussed.