Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dependency TypeDef used in a function declaration in another dependency #1326

Closed
maxime645 opened this issue Mar 25, 2019 · 1 comment · Fixed by #1346
Closed

Dependency TypeDef used in a function declaration in another dependency #1326

maxime645 opened this issue Mar 25, 2019 · 1 comment · Fixed by #1346
Assignees
Labels
Bug Functions TypeCobol Types User Visible Visible by the end user. Useful to priorize issue

Comments

@maxime645
Copy link
Contributor

Describe the bug
A Function Declaration defined in a dependency file using a Type from another dependency file will not be type checked at parsing time. The TypeDefinition property seems not to be filled when the function declaration is parsed.

To Reproduce
(Type)Cobol code that cause the bug : (if any)

       identification division.
       program-id. TCOSMPL2.
       data division.
       working-storage section.
       01 type1 typedef strict private.
       05 blabla pic X.
      
       01 s1 type DVZTEST2::Span.
       01 dat type date.
       01 t1 type type1.
      
       procedure division.
       INIT-LIBRARY.
      
           call DVZTEST1::GetTecMsg INPUT t1
           in-out s1
      
           call GetTecMsg input t1
           in-out s1
      
      
           goback.
      *----------------------------------------------------------------
       declare procedure GetTecMsg public
           input capt     type DVZTEST2::Span
           in-out msg     type DVZTEST2::Span
           .
       procedure division.
           continue
           .
       end-declare.
      
       end program TCOSMPL2.

In a dependency files

      *TypeCobol_Version:v1.2.5.20
       IDENTIFICATION DIVISION.
       PROGRAM-ID. DVZTEST1.
       PROCEDURE DIVISION.
       declare procedure GetTecMsg public
           input capt     type DVZTEST2::Span
           in-out msg     type DVZTEST2::Span
           .
       PROCEDURE DIVISION.
            continue
            .
       end-declare.
       end program DVZTEST1.

In another dependency file

      *TypeCobol_Version:v1.2.5.20
       IDENTIFICATION DIVISION.
       PROGRAM-ID. DVZTEST2.
       DATA DIVISION.
       WORKING-STORAGE SECTION.                                               
       01 Span typedef strict public.
           05 ptr    pointer.
           05 len       pic S9(5) comp-5.
                88 isEmpty   value 0.
                88 isEndPack value -1 -2.
                88 isOverflow value -2.
       PROCEDURE DIVISION.
            GOBACK.
       end program DVZTEST2.

Expected behavior
The line “call DVZTEST1::GetTecMsg INPUT t1” (line 15) should return the same error than line “call GetTecMsg input t1” (line 18) since the function declarations are the same.

@smedilol smedilol self-assigned this Mar 25, 2019
@smedilol smedilol added Bug User Visible Visible by the end user. Useful to priorize issue labels Mar 25, 2019
@smedilol
Copy link
Contributor

I'm rewriting the TypeCobolLinker, so I'll test if it solves this issue.

osmedile added a commit to osmedile/TypeCobol that referenced this issue Apr 1, 2019
Procedure paramters in dependencies are now resolved
even if they are not loaded in the correct order.
osmedile added a commit to osmedile/TypeCobol that referenced this issue Apr 2, 2019
…ypeCobolTeam#1327 Fix Global scope

TypeCobol refactoring but doesn't change its goals:
- Resolve type reference
- Detect circular reference between typedef
- Register link between type and variable in SymbolTable

TypeCobolLinker is now in CrossCheck phase.
It doesn't check/link dependencies directly but start Type
resolution from the main file.
This allows to fix TypeCobolTeam#1326 and TypeCobolTeam#1338.
It means the loading order of dependencies doesn't affect
the work of TypeCobolLinker.

As a TypeCobolLinker only start its work from the main
file, it means that unused Typedef and procedure in
dependencies won't be resolved anymore.
Type of used procedure will only be resolved,

WI TypeCobolTeam#1295 TypeCobolLinker can now detect circular references
between more than 2 types.
It can also handle circular references between main file
and dependencies.

WI TypeCobolTeam#1327 Fix global but it requires new TypeCobolLinker thats why it's
merged in the same commit.
The correct SymbolTable is now associated with global Node.
osmedile added a commit to osmedile/TypeCobol that referenced this issue Apr 2, 2019
Procedure paramters in dependencies are now resolved
even if they are not loaded in the correct order.
osmedile added a commit to osmedile/TypeCobol that referenced this issue Apr 3, 2019
…ypeCobolTeam#1327 Fix Global scope

TypeCobol refactoring but doesn't change its goals:
- Resolve type reference
- Detect circular reference between typedef
- Register link between type and variable in SymbolTable

TypeCobolLinker is now in CrossCheck phase.
It doesn't check/link dependencies directly but start Type
resolution from the main file.
This allows to fix TypeCobolTeam#1326 and TypeCobolTeam#1338.
It means the loading order of dependencies doesn't affect
the work of TypeCobolLinker.

As a TypeCobolLinker only start its work from the main
file, it means that unused Typedef and procedure in
dependencies won't be resolved anymore.
Type of used procedure will only be resolved,

WI TypeCobolTeam#1295 TypeCobolLinker can now detect circular references
between more than 2 types.
It can also handle circular references between main file
and dependencies.

WI TypeCobolTeam#1327 Fix global but it requires new TypeCobolLinker thats why it's
merged in the same commit.
The correct SymbolTable is now associated with global Node.
osmedile added a commit to osmedile/TypeCobol that referenced this issue Apr 3, 2019
Procedure paramters in dependencies are now resolved
even if they are not loaded in the correct order.
@maxime645 maxime645 mentioned this issue May 10, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Functions TypeCobol Types User Visible Visible by the end user. Useful to priorize issue
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants