Outline missing for struct fields defined via copybook

[EVLSDE]

Describe the bug Defining an external data structure in a copybook and copying it inside another rpg source via likeds leads to the outline not being correctly filled in the main source.

To Reproduce Let's define an external data structure in a copybook. Now use a /copy statement inside another rpg source. Define a data structure inside the rpg source which uses the externally described data structure from your copybook via likeds. In the copybook outline, the external data structure gets extended and you can see the fields. In the main outline, you'll only see the local struct but without fields. Completion items and linting errors ("no reference" for fields) get shown correctly, but the outline is missing.

RPG source: **free ctl-opt main(Main); /copy 'QCPYLESRC/somecopybook.rpgle'

dcl-proc Main; dcl-pi *n; end-pi;

dcl-ds SomeStruct likeds(GlobalStruct) inz;

end-proc;

Copy source: **free // data structure for file SomeFile dcl-ds GlobalStruct extname('SOMEFILE') qualified template; end-ds;

Expected behavior The outline should show the same fields in both sources if you just use a likeds.

Screenshots See example code given above

Environment

• Extension version v0.26.9
• IBM i OS version 7.4

Additional context In documentSymbols.ts, when structs are being extended, the path of a subItem is filtered against the currentPath. While the line number of the subItem is correctly set in the main source, the path is still pointing to the copybook. Similar to #325, the issue seems to be the parser.js while fetching local definitions in expandDs. After cloning the subItems, I should simply have added newItem.position.path = ds.position.path

[worksofliam]

This is intended behaviour. The outline view only shows explicit definitions in the current source as other languages do.

[EVLSDE]

Thanks for the quick response! I'm afraid we might be talking about different topics, so just to make sure: Everything that's defined in a copybook should just be in the copybook's outline - I'd totally agree with that.

So if you define a template data structure in a copybook (like GlobalStruct in my original example) I wouldn't want to see it in an outline including the copybook. But if you define a data structure in an rpg source (like SomeStruct in the example) I'd expect it to always build the outline including the sub fields, no matter if the data structure is using a template from a copybook (via likeds) or not.

~Right now if I define a template data structure in my copybook and code the sub fields by hand, I can see the sub fields in the outline of a locally defined struct using said template via /copy + likeds. But if I switch the template definition to extname, the list wont build up - it's just the struct without its children.~

Sorry, got that one wrong. Sub fields are never shown in the main source outline if the template is in a copybook, now matter how defined.

[worksofliam]

But if you define a data structure in an rpg source (like SomeStruct in the example) I'd expect it to always build the outline including the sub fields, no matter if the data structure is using a template from a copybook (via likeds) or not.

Yep, that is correct.

Perhaps there is a bug, and since you provided a test case, we should create one. I will do that now and get back to you.

[worksofliam]

@EVLSDE I have written a test case with your examples. To me, it looks like the parser is ok here so it's likely something in the language server code itself. I will dig further today.

Let me know if I am missing something:

https://github.com/codefori/vscode-rpgle/commit/6c335cb60a826e775834506407c001fb0372a9ea

[EVLSDE]

I have to apologize, seems I've been blinded by the "mighty RDI" this time. For example: If you open a TS source in vs code, create a class in script A and instantiate it in script B, you wont see the object props in the outline of script B, just the object name.

That means you were right all along - the extension works as intended and this would be an enhancement (which is still tempting as we're used to RDI).

[worksofliam]

@EVLSDE No problem. It would make sense to see the children members of the struct in the file - I will see about trying it out.

[allthom]

This look quite the same as issues I outlined in #313 and #308