Some syntactic diagnostic errors erroneously reported as semantic

[JoshuaKGoldberg]

Bug Report

🔎 Search Terms

syntax diagnostics errors semantics

🕗 Version & Regression Information

• This is the behavior in every version I tried, and I reviewed the FAQ for entries about diagnostics

⏯ Playground Link

Playground link with relevant code

💻 Code

declare const test: any;
@test const value = 2;

Alternately, here's a local snippet to run (requires a file.ts to exist on disk with the playground's contents):

const ts = require("typescript");

const program = ts.createProgram(["file.ts"], {});

function logDiagnostics(prefix, diagnostics) {
  console.log(
    `${prefix}:`,
    diagnostics.map((diagnostic) => diagnostic.messageText)
  );
}

logDiagnostics("Semantic", program.getSemanticDiagnostics());
logDiagnostics("Syntactic", program.getSyntacticDiagnostics());

Output:

Semantic: [ 'Decorators are not valid here.' ]
Syntactic: []

🙁 Actual behavior

Decorators are not valid here. should be emitted as a syntactic diagnostic.

🙂 Expected behavior

Decorators are not valid here. is emitted as a semantic diagnostic.

This difference is important because downstream tools like typescript-eslint might care about the difference. typescript-eslint/typescript-eslint#1852 -> typescript-eslint/typescript-eslint#6271 is a key example: we'd like to reuse TypeScript's source parsing to detect AST issues (which is needed because downstream ESLint rules should be able to assume they won't run on invalid ASTs e.g. like import; that are missing nodes).

I see the checker's grammar checking is where this and other decorator grammar diagnostics are added. Is there a reason they're not added to parse diagnostics in the parser?

[RyanCavanaugh]

The question of what's syntactic and what's semantic is a little fuzzy. For example, modifier order (public override, protected static, etc) could either be seen as a grammar production rule in which invalid orderings aren't legal, or a grammar that allows modifiers in any order but is covered by a semantic rule about which comes first.

The parser will permit certain productions to be parsed "without parse error"; this is beneficial in terms of not needing special error recovery, and nodes marked as not containing errors can be reused by the incremental parser.

So anyway you should really think of syntactic errors as roughly only being those which indicate that the parser can't make heads or tails of what's going on, not a bright line. Unfortunately I don't think we have a way to only get the grammar errors from the checker (the question of what's a grammar error vs a type error being a separate sandwich that needs slicing).

[typescript-bot]

This issue has been marked as 'Question' and has seen no recent activity. It has been automatically closed for house-keeping purposes. If you're still waiting on a response, questions are usually better suited to stackoverflow or the TypeScript Discord community.