-
Notifications
You must be signed in to change notification settings - Fork 26
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
Labels
Milestone
Comments
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.
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
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)
In a dependency files
In another dependency file
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.
The text was updated successfully, but these errors were encountered: