Provide Grammar Errors for JavaScript Files

[DanielRosenwasser]

Recently, we started reporting high-confidence errors for typos as suggestions in the language service. We believe that there is a set of grammar issues that are worth erroring on as well that are not reported today (e.g. duplicate block-scoped variables, extending multiple classes, rest parameters occurring before regular parameters, etc.)

Open questions:

• How do we implement this as part of our API?
• What sorts of errors are acceptable here?
• Would we be giving errors that run against the expectations of any popular runtimes, build tools, or syntax extensions?

[sandersn]

Here are my rough notes, cleaned up a little. This is only the binder errors.

Runtime Error

These errors are all errors in JS, at least in V8. Mostly they only apply in strict contexts: .mjs files and class bodies. Actually, the errors are good enough that they should use the same rule as for TS: any JS file that uses ES exports counts as a real ES module and is in strict mode. (Even though .js files are usually commonjs at present.)

These errors should always be provided to JS files.

Diagnostics.Cannot_redeclare_block_scoped_variable_0

const x = 1
var x = 1

Diagnostics.A_module_cannot_have_multiple_default_exports

also:

• Diagnostics.A_module_cannot_have_multiple_default_exports
• Diagnostics.Another_export_default_is_here
• Diagnostics.and_here <-- (!) this might be used elsewhere
• Diagnostics.The_first_export_default_is_here

export default 12;
export default 13;

Diagnostics.Identifier_expected_0_is_a_reserved_word_at_the_top_level_of_a_module

export default 12;
const await = 1

Diagnostics.Identifier_expected_0_is_a_reserved_word_in_strict_mode_Modules_are_automatically_in_strict_mode

const yield = 2
export default 12;

Diagnostics.Identifier_expected_0_is_a_reserved_word_that_cannot_be_used_here

async function f() {
  const await = 1
}

Diagnostics.Identifier_expected_0_is_a_reserved_word_that_cannot_be_used_here

function* f() {
  const yield = 1
}

Diagnostics.constructor_is_a_reserved_word

class C {
    #constructor = 1
}

Diagnostics.delete_cannot_be_called_on_an_identifier_in_strict_mode

class C {
    m() {
        function container(f) {
            delete f
        }
        var g = 1
        delete g
        delete container
    }
}

Diagnostics.Invalid_use_of_0_Class_definitions_are_automatically_in_strict_mode

class C {
    m() {
        const eval = 1
        const arguments = 2
    }
    g() {
    }
}

Diagnostics.Invalid_use_of_0_Modules_are_automatically_in_strict_mode

export default 13;
const eval = 1
const arguments = 2

Diagnostics.Invalid_use_of_0_in_strict_mode

"use strict" // this doesn't actually turn strict on or off
const eval = 1
const arguments = 2

Diagnostics.Octal_literals_are_not_allowed_in_strict_mode

class C {
    m() {
      return 010
    }
}

Diagnostics.with_statements_are_not_allowed_in_strict_mode

class C {
    m() {
      const n = 010
      with (n) {
        return toFixed()
      }
    }
}

Likely wrong

These errors indicate code that is likely wrong, but won't error.

I'm not sure whether to show these errors in plain JS files.

• Diagnostics.An_object_literal_cannot_have_multiple_properties_with_the_same_name_in_strict_mode

class C {
  m() {
    return { a: 1, a: 1 }
  }
}

(I'm not sure what 'strict mode' refers to here; the above test works fine in node for .js and .mjs)
From a JS perspective, this feels linty, so I don't think I'll include it.

• Diagnostics.A_label_is_not_allowed_here

    class C {
        m() {
            label: var x = 1
            break label
        }
    }

There are two reasons I can see for this error:

1. Intended object literal -- although it's only issued before declarations like var, function, etc, which are not valid property names.
2. You misunderstand the intent of labels, and try to use the label later.

I still think (1) is possible because there are surely some declarations that start with contextual keywords. And our error for (2) is abysmally misleading, even though when you run such a program, you'll get a clear runtime error. So I'm going to include this error, even though I'm going to skip the "Unused label" that applies to valid label locations.

Harmless/Could be intended

These errors indicate code that could be written by reasonable people trapped by circumstance into being careless.

Probably shouldn't show these errors in JS.

• Diagnostics.Duplicate_identifier_0
• Diagnostics.Unused_label
• Diagnostics.Identifier_expected_0_is_a_reserved_word_in_strict_mode_Class_definitions_are_automatically_in_strict_mode
• Diagnostics.Identifier_expected_0_is_a_reserved_word_in_strict_mode_Modules_are_automatically_in_strict_mode
• Diagnostics.Identifier_expected_0_is_a_reserved_word_in_strict_mode <-- (probably)
• Diagnostics.Unreachable_code_detected

Sir Not-Appearing-in-this-Language

These errors only apply to Typescript constructs or Typescript emit.

• Diagnostics.Enum_declarations_can_only_merge_with_namespace_or_other_enum_declarations
• Diagnostics.Did_you_mean_0
• Diagnostics.export_modifier_cannot_be_applied_to_ambient_modules_and_module_augmentations_since_they_are_always_visible
• Diagnostics.Pattern_0_can_have_at_most_one_Asterisk_character
• Diagnostics.Function_declarations_are_not_allowed_inside_blocks_in_strict_mode_when_targeting_ES3_or_ES5_Class_definitions_are_automatically_in_strict_mode
• Diagnostics.Function_declarations_are_not_allowed_inside_blocks_in_strict_mode_when_targeting_ES3_or_ES5_Modules_are_automatically_in_strict_mode
• Diagnostics.Function_declarations_are_not_allowed_inside_blocks_in_strict_mode_when_targeting_ES3_or_ES5
• Diagnostics.Modifiers_cannot_appear_here
• Diagnostics.Global_module_exports_may_only_appear_at_top_level
• Diagnostics.Global_module_exports_may_only_appear_in_module_files
• Diagnostics.Global_module_exports_may_only_appear_in_declaration_files
• Diagnostics.Duplicate_identifier_0

[sandersn]

@orta points out that it would be extremely useful to show

Diagnostics.Cannot_assign_to_0_because_it_is_a_constant

in JS when you try to += 'foo' to a const string, for example.

[DanielRosenwasser]

In the same vein, used-before-defined would also be helpful for let``/const variables