Parsing separates the identifier part of the link tag from its text, but
the editor should present an identifier followed by `()` as a single
identifier since people use that syntax as a function sigil.
I prefer `#'` personally, you know, xkcd 297, nudge nudge.
* Error on mapped types with properties
1. Error on properties of type literals with computed properties whose name is a
binary expression with `in`, because that's a good sign of a mapped
type.
2. Parse following properties on mapped types, and error on them.
3. Stop checking computed property names in (1) to avoid producing
errors based on misinterpreting mapped type syntax as an expression.
* add comment in types.ts
* Update API again
* Check interfaces and classes too
* Add missed check in updateMappedTypeNode
Previously, import assertion parsing would try to parse both { and },
even if both were missing. If both were missing, the error for } could
occur past the end of the file, causing an assertion.
Fixes#46364
* Ensure symbol key unique when target is a local symbol exported elsewhere
* Add test
* Support targets without declarations
* Best key yet
* A-ha moment
* Clean up types
* Update API
* Update unit test
* feat: add quick fix for types
* feat: add test case for quick fix of types
* feat: add did-you-mean error when Cannot_find_name_0 and Cannot_find_namespace_0
* feat: add Cannot_find_namespace_0_Did_you_mean_1 error and only suggest when resolve type
* feat: update baselines
* feat: update baselines
* feat: update baselines
* chore: fix style problem
* Always suggest spelling corrections
* suggest primitives instead of their wrappers
* Add primitives to suggestions
Instead of altering wrappers to look like primitives.
* add semicolons
* revert unneeded change
Co-authored-by: Nathan Shively-Sanders <293473+sandersn@users.noreply.github.com>
* Track source and target relationship stack depth seperately, only increase on change in value
* Add baselines for test from #43485
* Bail on unwrapping conditional constraints on the source side when the source conditional is already known to be spooling out of control
* More usage of isDeeplyNestedType to block _specifically_ conditional recursion on only one side
* Negative cases of getNarrowedType that match the exact type should be filtered out, even when generic
* Add test and fix for #44404
* Swap to manually specifying left and right recursion
* Rename Left -> Source, Right -> Target
Co-authored-by: Andrew Branch <andrew@wheream.io>
* Loosen check in getIndexTypeForMappedType to directly map property names when any indexy type is present
* Handle homomorphic mappings better in keyof, add specific relationship rule for relating generic keyof MappedType to handle remapped keys
* Remove trailing whitespace
Kagami Sascha Rosylight
Anders Hejlsberg
Andrew Branch
Adam Burgess
Daniel Rosenwasser
Oleksandr T
Nathan Shively-Sanders
Sidharth Vinod
Wesley Wigham
LowR
chenjigengandNathan Shively-Sanders
Orta Therox
Hiroshi Ogawa