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

Type checking #15

Closed
4 of 5 tasks
mrRachar opened this issue Aug 18, 2020 · 2 comments · Fixed by #28
Closed
4 of 5 tasks

Type checking #15

mrRachar opened this issue Aug 18, 2020 · 2 comments · Fixed by #28
Assignees
Labels
bug Something isn't working implemented Implemented, and on it's way to stable semantic check Problems with the semantic analysis stage urgent High priority and should be fixed ahead of other tasks

Comments

@mrRachar
Copy link
Collaborator

mrRachar commented Aug 18, 2020

Currently type checking doesn't seem to be properly implemented or checked. The following programme is able to pass through the semantic analysis stage of the compiler.

contract Test { }

Test :: (any) {
    public init() {
        var x: [Address] = 1
        var y: Bool = x
    }
}

The above example compiles without errors, although the generated code displays the same flaws (so the subsequent compiler will complain, although in such a way which is not useful for Flint users).

Note type checking does also not occur for return types:

contract Test { }

Test :: (any) {
    public init() {
        test()
    }

    func test() -> Bool {
        return 5
    }
}

Progress

  • Type checking for assignments
  • Type checking within expressions (_: Int + _: Bool should fail)
  • Type checking for field values (inside declarations)
  • Correctly handles surrounding context
  • Stable (tested) Some tests in place, will develop as issue Call checking #16 is worked on
@mrRachar mrRachar added bug Something isn't working urgent High priority and should be fixed ahead of other tasks semantic check Problems with the semantic analysis stage labels Aug 18, 2020
@mrRachar mrRachar added this to the Spec compatibility milestone Aug 18, 2020
@mrRachar mrRachar self-assigned this Aug 18, 2020
@mrRachar mrRachar mentioned this issue Aug 18, 2020
@mrRachar
Copy link
Collaborator Author

This got missed for two key reasons:

  1. There was an assumption that the Quartz compiler must at least do this
  2. Where the expectation was "it works" for the preëxisting codebase, only positive checking was in play. As when the types were right, it worked, this never came up as a problem

@mrRachar
Copy link
Collaborator Author

eWASM-tidy now has these fixes, it will propogate through the eWASM target project

@mrRachar mrRachar added the implemented Implemented, and on it's way to stable label Aug 18, 2020
@egroge egroge linked a pull request Sep 10, 2020 that will close this issue
@egroge egroge mentioned this issue Sep 10, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working implemented Implemented, and on it's way to stable semantic check Problems with the semantic analysis stage urgent High priority and should be fixed ahead of other tasks
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant