From 9248cec5a44adb46ba76a260c2bdd1579ef4b5b3 Mon Sep 17 00:00:00 2001
From: Toru Nagashima <star.ctor@gmail.com>
Date: Fri, 29 Mar 2019 18:54:51 +0900
Subject: [PATCH 1/5] New: Recoverable Error Handling

---
 .../2019-recoverable-error-handling/README.md | 121 ++++++++++++++++++
 1 file changed, 121 insertions(+)
 create mode 100644 designs/2019-recoverable-error-handling/README.md

diff --git a/designs/2019-recoverable-error-handling/README.md b/designs/2019-recoverable-error-handling/README.md
new file mode 100644
index 00000000..7a67a0e4
--- /dev/null
+++ b/designs/2019-recoverable-error-handling/README.md
@@ -0,0 +1,121 @@
+- Start Date: 2019-03-29
+- RFC PR: (leave this empty, to be filled in later)
+- Authors: Toru Nagashima &lt;[@mysticatea](https://github.com/mysticatea)&gt;
+
+# Recoverable Error Handling
+
+## Summary
+
+ESLint cannot verify source code if the code has a syntax error. However, we can make valid AST even if several kinds of syntax errors existed. For example, conflict of variable names doesn't break AST. This RFC calls such a syntax error as <a name="recoverable-errors" href="#recoverable-errors">"Recoverable Errors"</a>.
+
+This RFC adds handling of [Recoverable Errors] into ESLint.
+
+## Motivation
+
+The goal of this RFC is that improve ESLint experience by reducing "fixing an error makes more errors."
+
+## Detailed Design
+
+### Handling [Recoverable Errors] in ESLint
+
+1. `Linter` class passes `parserOptions.recoverableErrors` option with `true` to `espree` or custom parsers.
+1. If the object the parser returned has `recoverableErrors` property with an array, `Linter` class converts the errors to messages.
+
+Each element of `recoverableErrors` array has the following form.
+
+```jsonc
+{
+    "message": "Identifier 'foo' has already been declared",
+    "line": 1,      // 1-based line number.
+    "column": 10,   // 0-based column number.
+    "endLine": 1,   // Optional. 1-based line number.
+    "endColumn": 13 // Optional. 0-based column number.
+}
+```
+
+Then `Linter` class converts that to a message:
+
+```jsonc
+{
+    "fatal": false,
+    "ruleId": null,
+    "severity": 2,
+    "message": "Identifier 'foo' has already been declared",
+    "line": 1,      // 1-based line number.
+    "column": 11,   // 1-based column number.
+    "endLine": 1,   // Optional. 1-based line number.
+    "endColumn": 14 // Optional. 1-based column number.
+}
+```
+
+Directive comments such as `/*eslint-disable*/` cannot hide the messages of [Recoverable Errors].
+
+### Handling [Recoverable Errors] in Espree
+
+Acorn, the underlying of `espree`, has `raiseRecoverable(pos, message)` method to customize handling of [Recoverable Errors].
+
+If `options.recoverableErrors` was `true` then `espree` collects [Recoverable Errors] and returns the errors along with AST. Otherwise, `espree` throws syntax errors on [Recoverable Errors] as is currently.
+
+In `acorn@6.1.1`, there are the following [Recoverable Errors]:
+
+- "Comma is not permitted after the rest element"
+- "Parenthesized pattern"
+- "Redefinition of `__proto__` property"
+- "Redefinition of property"
+- "Binding XXX in strict mode"
+- "Assigning to XXX in strict mode"
+- "Argument name clash"
+- "Export 'XXX' is not defined"
+- "Multiple default clauses"
+- "Identifier 'XXX' has already been declared"
+- "Escape sequence in keyword XXX"
+- "Invalid regular expression: /a regexp/: An error description"
+
+> https://github.com/acornjs/acorn/search?q=raiseRecoverable
+
+### Other parsers
+
+This RFC doesn't contain the update of custom parsers. But this section considers if some popular custom parsers can applicate this feature.
+
+- `babel-eslint`<br>
+  I don't have enough knowledge about `babel-eslint` and [Recoverable Errors].
+- `@typescript-eslint/parser`<br>
+  TypeScript parser parses source code loosely, then provides syntax/semantic errors by API along with AST. So currently `@typescript-eslint/parser` manually throws syntax errors if the parse result has syntax/semantic errors. Therefore, it can provide [Recoverable Errors].
+- `vue-eslint-parser`<br>
+  It reports [HTML parse errors](https://html.spec.whatwg.org/multipage/parsing.html#parse-errors) and JavaScript syntax errors in `<template>` as [Recoverable Errors], then [vue/no-parsing-error](https://eslint.vuejs.org/rules/no-parsing-error.html) rule converts the errors to messages. Therefore, it can provide [Recoverable Errors].
+
+## Documentation
+
+- [Disabling Rules with Inline Comments](https://eslint.org/docs/user-guide/configuring#disabling-rules-with-inline-comments) section should note about [Recoverable Errors]. The directive comments cannot hide the [Recoverable Errors].
+- [Working with Custom Parsers](https://eslint.org/docs/developer-guide/working-with-custom-parsers) should describe about `options.recoverableErrors` and `recoverableErrors` property of the returned value. Custom parsers can use `recoverableErrors` property instead of throwing fatal errors to report syntax errors.
+
+## Drawbacks
+
+- I think the value of this feature is relatively small because people can verify source code after they fixed syntax errors. This feature provides just efficient.
+
+## Backwards Compatibility Analysis
+
+This is not a breaking change.
+
+- `Linter` class will handle a new property.
+- `espree` package will recognize `recoverableErrors` option and change that behavior if the `recoverableErrors` option was `true`.
+
+If users are depending `parserOptions.recoverableErrors`, possibly it will be broken. But I believe that we don't need to be worried about the case.
+
+## Alternatives
+
+- `vue-eslint-parser`'s way is an alternative.
+
+## Open Questions
+
+Nothing in particular.
+
+## Frequently Asked Questions
+
+Nothing in particular.
+
+## Related Discussions
+
+- https://github.com/eslint/eslint/issues/3815
+
+[Recoverable Errors]: #recoverable-errors

From fb6b014056e1a81cca7b47f480eb278e231ef2df Mon Sep 17 00:00:00 2001
From: Toru Nagashima <star.ctor@gmail.com>
Date: Fri, 29 Mar 2019 19:59:55 +0900
Subject: [PATCH 2/5] add two links

---
 designs/2019-recoverable-error-handling/README.md | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/designs/2019-recoverable-error-handling/README.md b/designs/2019-recoverable-error-handling/README.md
index 7a67a0e4..88ce3250 100644
--- a/designs/2019-recoverable-error-handling/README.md
+++ b/designs/2019-recoverable-error-handling/README.md
@@ -117,5 +117,7 @@ Nothing in particular.
 ## Related Discussions
 
 - https://github.com/eslint/eslint/issues/3815
+- https://github.com/eslint/espree/issues/368
+- https://github.com/eslint/eslint/pull/11509#pullrequestreview-220174854
 
 [Recoverable Errors]: #recoverable-errors

From fb44d0e062b137c930a3c788bceb541c38d0d4f2 Mon Sep 17 00:00:00 2001
From: Toru Nagashima <star.ctor@gmail.com>
Date: Tue, 2 Apr 2019 13:00:50 +0900
Subject: [PATCH 3/5] update RFC for the feedback

- It describes autofix.
- It describes exceptions which are caused by recoverable errors.
- It describes the scope of this feature; especially, this feature
  doesn't intend to support invalid AST.
---
 .../2019-recoverable-error-handling/README.md | 100 ++++++++++++------
 1 file changed, 66 insertions(+), 34 deletions(-)

diff --git a/designs/2019-recoverable-error-handling/README.md b/designs/2019-recoverable-error-handling/README.md
index 88ce3250..405e8518 100644
--- a/designs/2019-recoverable-error-handling/README.md
+++ b/designs/2019-recoverable-error-handling/README.md
@@ -14,41 +14,60 @@ This RFC adds handling of [Recoverable Errors] into ESLint.
 
 The goal of this RFC is that improve ESLint experience by reducing "fixing an error makes more errors."
 
+This feature intends to be used for the syntax errors which don't affect AST shape. For example, name conflicts, type errors, etc. This feature doesn't intend to support invalid AST.
+
 ## Detailed Design
 
 ### Handling [Recoverable Errors] in ESLint
 
-1. `Linter` class passes `parserOptions.recoverableErrors` option with `true` to `espree` or custom parsers.
-1. If the object the parser returned has `recoverableErrors` property with an array, `Linter` class converts the errors to messages.
-
-Each element of `recoverableErrors` array has the following form.
-
-```jsonc
-{
-    "message": "Identifier 'foo' has already been declared",
-    "line": 1,      // 1-based line number.
-    "column": 10,   // 0-based column number.
-    "endLine": 1,   // Optional. 1-based line number.
-    "endColumn": 13 // Optional. 0-based column number.
-}
-```
-
-Then `Linter` class converts that to a message:
-
-```jsonc
-{
-    "fatal": false,
-    "ruleId": null,
-    "severity": 2,
-    "message": "Identifier 'foo' has already been declared",
-    "line": 1,      // 1-based line number.
-    "column": 11,   // 1-based column number.
-    "endLine": 1,   // Optional. 1-based line number.
-    "endColumn": 14 // Optional. 1-based column number.
-}
-```
-
-Directive comments such as `/*eslint-disable*/` cannot hide the messages of [Recoverable Errors].
+- `Linter` class passes `parserOptions.recoverableErrors` option with `true` to `espree` or custom parsers.
+- If the object the parser returned has `recoverableErrors` property with an array, `Linter` class converts the errors to messages.
+
+    Each element of `recoverableErrors` array has the following form.
+
+    ```jsonc
+    {
+        "message": "Identifier 'foo' has already been declared",
+        "line": 1,      // 1-based line number.
+        "column": 10,   // 0-based column number.
+        "endLine": 1,   // Optional. 1-based line number.
+        "endColumn": 13 // Optional. 0-based column number.
+    }
+    ```
+
+    Then `Linter` class converts that to a message:
+
+    ```jsonc
+    {
+        "fatal": true,
+        "ruleId": null,
+        "severity": 2,
+        "message": "Identifier 'foo' has already been declared",
+        "line": 1,      // 1-based line number.
+        "column": 11,   // 1-based column number.
+        "endLine": 1,   // Optional. 1-based line number.
+        "endColumn": 14 // Optional. 1-based column number.
+    }
+    ```
+
+- Directive comments such as `/*eslint-disable*/` cannot hide the messages of [Recoverable Errors].
+- If the parser returned any [Recoverable Errors], the `Linter` disables autofix as making [`disableFixes` option](https://github.com/eslint/rfcs/tree/master/designs/2018-processors-improvements#changes-to-cliengine-and-linter) `true` internally because it's considered not safe.
+- If the parser returned any [Recoverable Errors], the `Linter` catches exceptions which were thrown from rules and reports the exceptions as regular messages rather than crash in order to provide linting messages as best effort basis. For example,
+
+    ```jsonc
+    {
+        "fatal": true,
+        "ruleId": "a-rule",
+        "severity": 2,
+        "message": "'a-rule' failed to lint the code because of syntax error(s).",
+        "line": 1,
+        "column": 1,
+        "endLine": 1,
+        "endColumn": 1
+    }
+    ```
+
+    If a rule has an exception and regular messages, the `Linter` drops the regular messages to avoid confusion of wrong messages.
 
 ### Handling [Recoverable Errors] in Espree
 
@@ -73,7 +92,7 @@ In `acorn@6.1.1`, there are the following [Recoverable Errors]:
 
 > https://github.com/acornjs/acorn/search?q=raiseRecoverable
 
-### Other parsers
+### Handling [Recoverable Errors] in Other Parsers
 
 This RFC doesn't contain the update of custom parsers. But this section considers if some popular custom parsers can applicate this feature.
 
@@ -84,6 +103,18 @@ This RFC doesn't contain the update of custom parsers. But this section consider
 - `vue-eslint-parser`<br>
   It reports [HTML parse errors](https://html.spec.whatwg.org/multipage/parsing.html#parse-errors) and JavaScript syntax errors in `<template>` as [Recoverable Errors], then [vue/no-parsing-error](https://eslint.vuejs.org/rules/no-parsing-error.html) rule converts the errors to messages. Therefore, it can provide [Recoverable Errors].
 
+### How should custom parsers use AST with [Recoverable Errors]?
+
+This feature intends to be used for the syntax errors which don't affect AST shape. For example, name conflicts, type errors, etc. This feature doesn't intend to support invalid AST.
+
+If recovering of a syntax error makes invalid AST as ESTree or unexpected mapping between AST and tokens, it should not be [Recoverable Errors].
+
+### How should rules support AST with [Recoverable Errors]?
+
+If given AST is valid along with [Recoverable Errors], rules should support that case.
+
+If mapping between AST nodes and tokens was broken, probably rules cannot support that case.
+
 ## Documentation
 
 - [Disabling Rules with Inline Comments](https://eslint.org/docs/user-guide/configuring#disabling-rules-with-inline-comments) section should note about [Recoverable Errors]. The directive comments cannot hide the [Recoverable Errors].
@@ -91,7 +122,8 @@ This RFC doesn't contain the update of custom parsers. But this section consider
 
 ## Drawbacks
 
-- I think the value of this feature is relatively small because people can verify source code after they fixed syntax errors. This feature provides just efficient.
+- The value of this feature is relatively small because people can verify source code after they fixed syntax errors. This feature provides just efficient.
+- This feature makes core rules more complex if we wanted to support widely situations.
 
 ## Backwards Compatibility Analysis
 
@@ -104,7 +136,7 @@ If users are depending `parserOptions.recoverableErrors`, possibly it will be br
 
 ## Alternatives
 
-- `vue-eslint-parser`'s way is an alternative.
+- `vue-eslint-parser`'s way is an alternative; A custom parser returns `errors` property along with AST and a plugin rule reports the errors in the property. But people can disable plugin rules, so it's not proper as the way that shows syntax errors.
 
 ## Open Questions
 

From 61fb2e6aff2ba865e68ad80408fb2580cbcce535 Mon Sep 17 00:00:00 2001
From: Toru Nagashima <star.ctor@gmail.com>
Date: Fri, 7 Jun 2019 18:33:00 +0900
Subject: [PATCH 4/5] update for the feedback on TSC meeting

---
 .../2019-recoverable-error-handling/README.md | 64 +++++++++++++------
 1 file changed, 45 insertions(+), 19 deletions(-)

diff --git a/designs/2019-recoverable-error-handling/README.md b/designs/2019-recoverable-error-handling/README.md
index 405e8518..63039b36 100644
--- a/designs/2019-recoverable-error-handling/README.md
+++ b/designs/2019-recoverable-error-handling/README.md
@@ -1,5 +1,5 @@
 - Start Date: 2019-03-29
-- RFC PR: (leave this empty, to be filled in later)
+- RFC PR: https://github.com/eslint/rfcs/pull/19
 - Authors: Toru Nagashima &lt;[@mysticatea](https://github.com/mysticatea)&gt;
 
 # Recoverable Error Handling
@@ -18,10 +18,10 @@ This feature intends to be used for the syntax errors which don't affect AST sha
 
 ## Detailed Design
 
-### Handling [Recoverable Errors] in ESLint
+### § Handling [Recoverable Errors] in ESLint
 
 - `Linter` class passes `parserOptions.recoverableErrors` option with `true` to `espree` or custom parsers.
-- If the object the parser returned has `recoverableErrors` property with an array, `Linter` class converts the errors to messages.
+- If the object the parser returned has `recoverableErrors` property with an array, or if the error the parser thrown has `recoverableErrors` property with an array, `Linter` class converts the errors to messages. 
 
     Each element of `recoverableErrors` array has the following form.
 
@@ -50,16 +50,36 @@ This feature intends to be used for the syntax errors which don't affect AST sha
     }
     ```
 
-- Directive comments such as `/*eslint-disable*/` cannot hide the messages of [Recoverable Errors].
-- If the parser returned any [Recoverable Errors], the `Linter` disables autofix as making [`disableFixes` option](https://github.com/eslint/rfcs/tree/master/designs/2018-processors-improvements#changes-to-cliengine-and-linter) `true` internally because it's considered not safe.
-- If the parser returned any [Recoverable Errors], the `Linter` catches exceptions which were thrown from rules and reports the exceptions as regular messages rather than crash in order to provide linting messages as best effort basis. For example,
+- Directive comments such as `/*eslint-disable*/` cannot hide the messages of recoverable errors.
+- ESLint doesn't run any rules if a recoverable error existed.
+
+Practically, this is the support for multiple syntax errors.
+
+#### `verifyOnRecoverableParsingErrors` option
+
+`verifyOnRecoverableParsingErrors` option is the following three:
+
+- `--verify-on-recoverable-parsing-errors` CLI option
+- `verifyOnRecoverableParsingErrors` in `CLIEngine` constructor option (`boolean`, default is `false`)
+- `verifyOnRecoverableParsingErrors` in `Linter#verify()` option (`boolean`, default is `false`)
+
+<table><tr><td>
+<p>And <a href="https://github.com/eslint/rfcs/pull/22">#22</a> <code>coreOptions.verifyOnRecoverableParsingErrors</code> in config files if both RFCs accepted.
+</td></tr></table>
+
+If the `verifyOnRecoverableParsingErrors` option was given, ESLint runs configured rules even if the parser returned recoverable errors. In that case, ESLint additionally controls lint messages to avoid confusion.
+
+If the parser returned any recoverable errors:
+
+- the `Linter` disables autofix by making [`disableFixes` option](https://eslint.org/docs/6.0.0/developer-guide/nodejs-api#linterverify) `true` internally as autofix is considered not safe.
+- the `Linter` catches exceptions which were thrown from rules and reports the exceptions as regular messages rather than crash in order to provide linting messages as best effort basis. For example,
 
     ```jsonc
     {
         "fatal": true,
         "ruleId": "a-rule",
         "severity": 2,
-        "message": "'a-rule' failed to lint the code because of syntax error(s).",
+        "message": "'a-rule' failed to lint the code because of parsing error(s).",
         "line": 1,
         "column": 1,
         "endLine": 1,
@@ -69,13 +89,13 @@ This feature intends to be used for the syntax errors which don't affect AST sha
 
     If a rule has an exception and regular messages, the `Linter` drops the regular messages to avoid confusion of wrong messages.
 
-### Handling [Recoverable Errors] in Espree
+### § Handling [Recoverable Errors] in Espree
 
-Acorn, the underlying of `espree`, has `raiseRecoverable(pos, message)` method to customize handling of [Recoverable Errors].
+Acorn, the underlying of `espree`, has `raiseRecoverable(pos, message)` method to customize handling of recoverable errors.
 
-If `options.recoverableErrors` was `true` then `espree` collects [Recoverable Errors] and returns the errors along with AST. Otherwise, `espree` throws syntax errors on [Recoverable Errors] as is currently.
+If `options.recoverableErrors` was `true` then `espree` collects recoverable errors and returns the errors along with AST. Otherwise, `espree` throws syntax errors on recoverable errors as is currently.
 
-In `acorn@6.1.1`, there are the following [Recoverable Errors]:
+In `acorn@6.1.1`, there are the following recoverable errors:
 
 - "Comma is not permitted after the rest element"
 - "Parenthesized pattern"
@@ -92,33 +112,39 @@ In `acorn@6.1.1`, there are the following [Recoverable Errors]:
 
 > https://github.com/acornjs/acorn/search?q=raiseRecoverable
 
-### Handling [Recoverable Errors] in Other Parsers
+<table><tr><td>
+<p>A crazy idea is that we can make the parsing errors which are caused by older <code>ecmaVersion</code> recoverable. The parser parses code with the latest <code>ecmaVersion</code> always, then reports newer syntaxes as recoverable errors with understandable messages such as "async functions are not supported in ES5. Please set '2017' to 'parserOptions.ecmaVersion'."
+</td></tr></table>
+
+### § Handling [Recoverable Errors] in Other Parsers
 
 This RFC doesn't contain the update of custom parsers. But this section considers if some popular custom parsers can applicate this feature.
 
 - `babel-eslint`<br>
-  I don't have enough knowledge about `babel-eslint` and [Recoverable Errors].
+  I don't have enough knowledge about `babel-eslint` and recoverable errors.
 - `@typescript-eslint/parser`<br>
-  TypeScript parser parses source code loosely, then provides syntax/semantic errors by API along with AST. So currently `@typescript-eslint/parser` manually throws syntax errors if the parse result has syntax/semantic errors. Therefore, it can provide [Recoverable Errors].
+  TypeScript parser parses source code loosely, then provides syntax/semantic errors by API along with AST. So currently `@typescript-eslint/parser` manually throws syntax errors if the parse result has syntax/semantic errors. Therefore, it can provide recoverable errors.
 - `vue-eslint-parser`<br>
-  It reports [HTML parse errors](https://html.spec.whatwg.org/multipage/parsing.html#parse-errors) and JavaScript syntax errors in `<template>` as [Recoverable Errors], then [vue/no-parsing-error](https://eslint.vuejs.org/rules/no-parsing-error.html) rule converts the errors to messages. Therefore, it can provide [Recoverable Errors].
+  It reports [HTML parse errors](https://html.spec.whatwg.org/multipage/parsing.html#parse-errors) and JavaScript syntax errors in `<template>` as recoverable errors, then [vue/no-parsing-error](https://eslint.vuejs.org/rules/no-parsing-error.html) rule converts the errors to messages. Therefore, it can provide recoverable errors.
 
 ### How should custom parsers use AST with [Recoverable Errors]?
 
 This feature intends to be used for the syntax errors which don't affect AST shape. For example, name conflicts, type errors, etc. This feature doesn't intend to support invalid AST.
 
-If recovering of a syntax error makes invalid AST as ESTree or unexpected mapping between AST and tokens, it should not be [Recoverable Errors].
+If recovering of a syntax error makes invalid AST as ESTree or unexpected mapping between AST and tokens, it should not be recoverable errors.
 
 ### How should rules support AST with [Recoverable Errors]?
 
-If given AST is valid along with [Recoverable Errors], rules should support that case.
+If given AST is valid along with recoverable errors, rules should support that case.
 
 If mapping between AST nodes and tokens was broken, probably rules cannot support that case.
 
 ## Documentation
 
-- [Disabling Rules with Inline Comments](https://eslint.org/docs/user-guide/configuring#disabling-rules-with-inline-comments) section should note about [Recoverable Errors]. The directive comments cannot hide the [Recoverable Errors].
-- [Working with Custom Parsers](https://eslint.org/docs/developer-guide/working-with-custom-parsers) should describe about `options.recoverableErrors` and `recoverableErrors` property of the returned value. Custom parsers can use `recoverableErrors` property instead of throwing fatal errors to report syntax errors.
+- [Disabling Rules with Inline Comments](https://eslint.org/docs/user-guide/configuring#disabling-rules-with-inline-comments) section should note about recoverable errors. The directive comments cannot hide the recoverable errors.
+- [Working with Custom Parsers](https://eslint.org/docs/developer-guide/working-with-custom-parsers) page should describe about `options.recoverableErrors` and `recoverableErrors` property of the returned value. Custom parsers can use `recoverableErrors` property instead of throwing fatal errors to report syntax errors.
+- [Command Line Interface](https://eslint.org/docs/user-guide/command-line-interface) page should describe the newly `--verify-on-recoverable-parsing-errors` option.
+- [Node.js API](https://eslint.org/docs/6.0.0/developer-guide/nodejs-api) page should describe the newly `verifyOnRecoverableParsingErrors` option.
 
 ## Drawbacks
 

From 33a92028e867a3ab731cf42b8a2c66428d17177a Mon Sep 17 00:00:00 2001
From: Toru Nagashima <star.ctor@gmail.com>
Date: Fri, 7 Jun 2019 18:38:16 +0900
Subject: [PATCH 5/5] trivial fix

---
 designs/2019-recoverable-error-handling/README.md | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/designs/2019-recoverable-error-handling/README.md b/designs/2019-recoverable-error-handling/README.md
index 63039b36..44832a64 100644
--- a/designs/2019-recoverable-error-handling/README.md
+++ b/designs/2019-recoverable-error-handling/README.md
@@ -64,7 +64,8 @@ Practically, this is the support for multiple syntax errors.
 - `verifyOnRecoverableParsingErrors` in `Linter#verify()` option (`boolean`, default is `false`)
 
 <table><tr><td>
-<p>And <a href="https://github.com/eslint/rfcs/pull/22">#22</a> <code>coreOptions.verifyOnRecoverableParsingErrors</code> in config files if both RFCs accepted.
+<b>An aside:</b><br>
+And <a href="https://github.com/eslint/rfcs/pull/22">#22</a> <code>coreOptions.verifyOnRecoverableParsingErrors</code> in config files if both RFCs accepted.
 </td></tr></table>
 
 If the `verifyOnRecoverableParsingErrors` option was given, ESLint runs configured rules even if the parser returned recoverable errors. In that case, ESLint additionally controls lint messages to avoid confusion.
@@ -113,7 +114,8 @@ In `acorn@6.1.1`, there are the following recoverable errors:
 > https://github.com/acornjs/acorn/search?q=raiseRecoverable
 
 <table><tr><td>
-<p>A crazy idea is that we can make the parsing errors which are caused by older <code>ecmaVersion</code> recoverable. The parser parses code with the latest <code>ecmaVersion</code> always, then reports newer syntaxes as recoverable errors with understandable messages such as "async functions are not supported in ES5. Please set '2017' to 'parserOptions.ecmaVersion'."
+<b>An aside:</b><br>
+A crazy idea is that we can make the parsing errors which are caused by older <code>ecmaVersion</code> recoverable. The parser parses code with the latest <code>ecmaVersion</code> always, then reports newer syntaxes as recoverable errors with understandable messages such as "async functions are not supported in ES5. Please set '2017' to 'parserOptions.ecmaVersion'."
 </td></tr></table>
 
 ### § Handling [Recoverable Errors] in Other Parsers