Skip to content
This repository was archived by the owner on Jun 15, 2023. It is now read-only.

Assertion of parseJsImport fails #593

Closed
wants to merge 2 commits into from

Conversation

Sehun0819
Copy link
Contributor

Assertion in parseJsImport function can fail, so I guess it should be properly treated instead of assertion.

  • Representative example:
    import@

The problem is, parseJsFfiDeclaration happens to return None which violates assertion.
I patched it by handling None case with an empty declaration, but I'm not sure it is a right way.

src/res_core.ml Outdated
@@ -5411,7 +5411,7 @@ and parseJsImport ~startPos ~attrs p =
let decl =
match parseJsFfiDeclaration p with
| Some decl -> decl
| None -> assert false
| None -> JsFfi.emptyDecl p.startPos
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See how other errors are handled.
E.g. just a few lines above here:

Parser.err ~startPos:attrLoc.loc_start ~endPos:attrLoc.loc_end p
        (Diagnostics.message (ErrorMessages.attributeWithoutNode attr));

Currently it goes all the way to the end of the file silently (e.g. in the provided test).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also see this example for where to define the default value to use (inside Recover:

    Parser.err p (Diagnostics.unexpected token p.breadcrumbs);
    Recover.defaultModuleExpr ()

@Sehun0819
Copy link
Contributor Author

@cristianoc Please check what I added for error handling.
And, do you mean it's better to define the default value(JsFfi.emptyDecl, I made) inside Recover module?
It seems that all default values in Recover are Ast of Ocaml compiler, while Js ffi decls are not.

@IwanKaramazow
Copy link
Contributor

FWIW import was a leftover from an experiment that we were never able to ship. Seems like the community found it a very bad thing (#217). Maybe the code path in the parser should just be removed?

@Sehun0819
Copy link
Contributor Author

@IwanKaramazow Thank you for informing of what was going on.
I had been curious because the source code seemed to accept more grammar than documentation, finally got an answer :)

@cristianoc
Copy link
Contributor

Let's remove it.

@cristianoc
Copy link
Contributor

I guess it means starting over with this PR

@Sehun0819
Copy link
Contributor Author

Then, should I close this PR? 🤔

@cristianoc
Copy link
Contributor

Or just undo the changes. Don't think anything will stay.

@cristianoc
Copy link
Contributor

The idea is to literally remove parsing "import".

@cristianoc
Copy link
Contributor

The same goes for "export".

@cristianoc
Copy link
Contributor

Here's what it would look like: #597

after removing all the resulting dead code reported from the analysis which runs on make test.

The same goes for export.

@Sehun0819 Sehun0819 closed this Jul 3, 2022
@Sehun0819 Sehun0819 deleted the fixcrash branch July 7, 2022 06:48
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants