[flang-commits] [flang] [Flang][OpenMP] Fix implicit symbol resolution for USE-renamed arrays (PR #189215)

[Aditya Trivedi via flang-commits]

adit4443ya wrote:

Hi Kiran,

Thanks for the review! I've removed all the unrelated `clang-format` changes and expanded the commit summary as requested.

Regarding your suggestion to associate the OpenMP region directly with the local renamed symbol (the `UseDetails` alias) instead of bypassing it to the ultimate symbol: I completely agreed this would be ideal to ensure local modifications track correctly. I actually tried implementing it exactly like this:

```diff
    auto makeSymbol = [&](Symbol::Flags flags) {
-      const Symbol *hostSymbol = lastDeclSymbol ? lastDeclSymbol : &symbol->GetUltimate();
+      const Symbol *ultimate = &symbol->GetUltimate();
+      const bool isRenamed = symbol->name().ToString() != ultimate->name().ToString();
+      const Symbol *hostSymbol = lastDeclSymbol ? lastDeclSymbol : (isRenamed ? symbol : ultimate);
```

Unfortunately, it turns out Flang's internal semantic engine (`ResolveNamesVisitor`) fundamentally segmentation faults if an OpenMP `HostAssocDetails` points directly to a `UseDetails` pointer instead of a concrete `EntityDetails`. Pushing that change caused 344 semantic tests in the CI to silently abort (core dumped).

Because the compiler currently requires the origin link to be the ultimate symbol to prevent crashing, I've stuck to my original workaround: maintaining the `GetUltimate()` association anchor strictly for stability, but safely overriding the `SourceName` explicitly for aliases. This preserves the local name (e.g. `s_ary`), preventing the dimension collision (#185344), while keeping all 344 tests 100% green. 

The updated test cases successfully pass semantic checks natively! Let me know what you think.

https://github.com/llvm/llvm-project/pull/189215