Skip to content

fix: module error recovery#1031

Merged
ahabhgk merged 7 commits intomainfrom
entry-error-minify
Nov 8, 2022
Merged

fix: module error recovery#1031
ahabhgk merged 7 commits intomainfrom
entry-error-minify

Conversation

@ahabhgk
Copy link
Copy Markdown
Contributor

@ahabhgk ahabhgk commented Nov 4, 2022

Summary

fixes #1026 #1042 #973

Test Plan

Related issue (if exists)

Further reading

For webpack, NormalModule has an error field, in build webpack will assign the error field according the loaders or parse result, in codeGeneration webpack will generate different code according the error field. In this implementation I merged the source field and the error field by enum.

@ahabhgk ahabhgk requested a review from h-a-n-a November 4, 2022 08:46
@ahabhgk ahabhgk force-pushed the entry-error-minify branch from 860b385 to f24aa09 Compare November 4, 2022 13:03
@ahabhgk ahabhgk changed the title fix: entry module code error leads to minify failed fix: module parse error tolerant Nov 4, 2022
@ahabhgk ahabhgk changed the title fix: module parse error tolerant fix: module parse error recovery Nov 4, 2022
@h-a-n-a
Copy link
Copy Markdown
Contributor

h-a-n-a commented Nov 7, 2022

Is this a workaround? Can you provide more context about the impl of Webpack, that might help alot?

@ahabhgk
Copy link
Copy Markdown
Contributor Author

ahabhgk commented Nov 7, 2022

No, it's not a workaround. For webpack, NormalModule has an error field, in build webpack will assign the error field according the loaders or parse result, in codeGeneration webpack will generate different code according the error field. In this implementation I merged the source field and the error field by enum. @h-a-n-a

@@ -0,0 +1,19 @@
try {
require("./recoverable.js");
require("./non-recoverable.js");
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Can you shed more light on the intention of splitting these two?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Recoverable means 'whether these errors recoverable'. For example, let let = let in strict mode is a recoverable error, so parse_file_as_module will return Ok and errors is not empty, ##!!## is not a recoverable error, so parse_file_as_module will return Err.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

The naming of these two error types seems introduced by SWC, not by the spec, it's kind of confusing for reviewer.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Actually it is called 'early error' in the spec, but seems swc call it recoverable error.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

The spec also defines that:

All errors that are not early errors are runtime errors.

The fact is the snippet of ##!!## is not even Lexical grammarly right because in order to become an early error you have to be a semantic error in the first place and it's neither a runtime error. so I don't think the naming here is a good choice. Following SWC's wording makes people confused more.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

What name do you suggest?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I would like to call the recoverable error an semantic-early-error like what you suggested and the non-recoverable a parse-error. Just an advice.

@h-a-n-a
Copy link
Copy Markdown
Contributor

h-a-n-a commented Nov 7, 2022

No, it's not a workaround. For webpack, NormalModule has an error field, in build webpack will assign the error field according the loaders or parse result, in codeGeneration webpack will generate different code according the error field. In this implementation I merged the source field and the error field by enum. @h-a-n-a

LGTM, please make sure CI passed before merge. Would you mind pasting these to the description part of this PR? Developers in the future may refer to this (comment maybe skipped by quick viewers).

@ahabhgk ahabhgk changed the title fix: module parse error recovery fix: module error recovery Nov 7, 2022
Error::TraceableError(v) => write!(f, "{}", v),
Error::Io { source } => write!(f, "{source}"),
Error::Anyhow { source } => write!(f, "{source}"),
Error::BatchErrors(errs) => write!(
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Remove thiserror because of this line.

@ahabhgk ahabhgk merged commit 25299f7 into main Nov 8, 2022
@ahabhgk ahabhgk deleted the entry-error-minify branch November 8, 2022 03:29
@h-a-n-a
Copy link
Copy Markdown
Contributor

h-a-n-a commented Nov 8, 2022

!snapshot

@github-actions
Copy link
Copy Markdown
Contributor

github-actions bot commented Nov 8, 2022

0.0.0-20221108071754

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

3 participants