gandm / language-babel

ES2017, flow, React JSX and GraphQL grammar and transpilation for ATOM
https://atom.io/packages/language-babel
MIT License
476 stars 83 forks source link

Flow generics in function call break syntax highlighting #508

Open Daniel15 opened 6 years ago

Daniel15 commented 6 years ago
function before() { }
doStuff<Foo>(foo);
doStuff<Bar>(bar);
function after() { }

Notice how the second doStuff call, and the after function are both not highlighted correctly.

I can't remember which Flow version added this, but this is valid Flow syntax to explicitly state the generic type rather than letting Flow infer it.

bsmith-cycorp commented 6 years ago

+1 to this, it's really problematic and still happening

felixmc commented 6 years ago

+1 experiencing this as well with Atom 1.31.1 and language-babel 2.84.0

dado3212 commented 6 years ago

Still experiencing with language-babel 2.85.0.

nmn commented 5 years ago

Any updates on this? I would help with a PR, but I don't understand how the language grammars work.

My understanding is that in the regex for matching a function call, you need to add support for optional generics before argument list.

Then I tested it in BabylonV7 using astexplorer, and babel failed to parse it as well. Apparently BabylonV7 parses correctly as long as the @flow pragma is part of the first comment on the file.

Link to type definition in Babel-parser: https://github.com/babel/babel/blob/85b7154f91c04a50fbaac584897ba7f5bd15bab2/packages/babel-types/src/definitions/core.js#L149

M-TGH commented 5 years ago

Did some digging around but ultimately couldn't really get it to work. I assume it's not too much different as the bits and pieces that are in to get generics to work on function declarations, e.g: https://github.com/gandm/language-babel/blob/d7d260522eb0f6528ea8558beb1bda54c5d25eba/grammars/Babel%20Language.json#L79

Would be great if someone with some Atom Grammars experience could take a look at this.

SpainTrain commented 5 years ago

Since parameterized calls work when their expression is somehow wrapped (by braces, parentheses, etc.), e.g.,

(fn<T>(varargs)) //works
const fn2 = () => { return fn<T>(varargs) } // works

fn<T>(varargs) // causes bug in question
const fn2 = () => fn<T>(varargs) // causes bug in question

I think the offender here may be literal-function-call , which is the relevant expression type. My guess is that we need a new flowtype-polymorphs pattern that captures a parameterized function call, then add that as an include to the literal-function-call definition.

I will continue working on this, but would love pointers/suggestions from maintainers or anyone familiar with these grammars.

omninonsense commented 5 years ago

Bumping this, because it's still broken.

The "best" workaround I have fund is to use Flow-only-code comments inline (ie /*::…*/, eg const r = f/*::<TypeArg>*/(x)), but that looks horrendous:

const [highlight, setHighlight] = React.useState/*::<[number, number] | null>*/(null)