* Add test case for 'useUnknownInCatchVariables'.
* Add new 'useUnknownInCatchVariables' flag.
* Accepted baselines.
* Add test for catch variable explicitly typed as 'any'.
* Accepted baselines.
* Move option under 'strict'.
* Accepted baselines.
* 'useUnknownInCatchVariables' is strict in command line help.
* Update the category descriptions for the tsconfig options
* Gets tests green
* Whitespace change
* Drop command line options from --init
* Go back to the old re-build baseline
* Fix numbers
* Remove formatting options from --showconfig
* Dpon't show output formatting changes in showConfig
* Update baselines
* Update baselines
* Tests to baseline tsserver instead of checking
Also ensures inferred and auto import projects have name per project service
* Log structureIsReused value
* more baselines
Eg. program can backup and restore state changing the state object and we want to release program on the correct one
This ensure program is released correctly when there are declaration emit errors during tsc --build
* Add unqualified JSDoc member references
This allows unqualified references like:
```ts
class Zero {
/** @param buddy Must be {@link D_HORSE} or {@link D_DOG}. */
deploy(buddy: number) { }
static D_HORSE = 1
static D_DOG = 2
}
```
I surveyed @see and @link again to estimate how common this is. I found
a little over 200 uses, which is around 2%. Sorted by frequency, this
*is* the next feature on the list, along with the `module:` prefix.
So I think this is about the right point to stop adding code.
In this case, however, I liked most of the uses -- there were a lot
of deprecated functions that referenced a function just below, where it
would be wordy to qualify the name, but the reader would benefit from a
link.
Note that unqualified references do *not* work inside type or object
literals. The code I ended up with is quite complicated and I didn't
observe any uses in the wild.
Fixes#43595
* Remove type/object literal container check
Since they don't work anyway
* Cache parsed path mapping patterns
If a project has many of them (e.g. 1800), parsing the patterns
repeatedly can take up a lot of time.
* Move cache to ConfigFileSpecs
* Inline constants
* Simplify cache access
* Simplify or optimize regexes with polynomial time worst cases
* PR feedback & cleanup
Co-authored-by: David Michon <dmichon-msft@users.noreply.github.com>
* Use builtin scanner function for checking whitespace in fallback method (its faster)
Co-authored-by: David Michon <dmichon-msft@users.noreply.github.com>
* Ensure static index signatures have an errorNode available
* Lookup static index signature declarations in the right symbol table, stop checking prototype props
Previously, changes to the wiki would get merged to the public repo in a
once-a-week action. This significantly revises this, making the two
sides be mirrors (up to the few seconds it takes to do a merge).
This is driven by a minimal-ish yaml file in both sides (`TypeScript`
and `TypeScript-wiki`) that *always* works from the script in the public
repo.
The two action specs are nearly identical, but there are some differences:
- On the main repo, trigger on a `gollum` event, and in the wiki repo
the usual (pushes, schedule, manual). (The schedule run is kept as
a just-in-case, and it's now running twice a week.)
- The filename is `sync-wiki` on the TS side and just `sync` in the
wiki. (Good to avoid confusion if both files somehow find
themselves in the same neighborhood.)
- The secret names are different since I used the name that already
exists in each side.
The script does *not* start with a checkout of its repository. Doing
this in the TS side would be redundant (it would get the TS tree) and
slow. Instead, it's always cloning the public wiki repo (`DASHREMOTE`,
since its url is `.../TypeScript-wiki`) and then fetching into it the
repo of the rendered wiki (`DOTREMOTE`, with a `.../TypeScript.wiki`)
url.
Also revised the README, since they should always be mirrored with this
change, and therefore there is no "source of truth".
* Add @linkcode and @linkplain tags
They are just like @link tags but request fixed-width and normal
presentation, respectively.
Fixes#43935
* revert JSDocComment -> JSDoc SyntaxKind rename
* update API baselines
* fix lint
* Kick out of normalizePath if there's nothing to do
...using `relativePathSegmentRegExp`.
Bonus: use a regex to handle "/./" to avoid splitting and joining in a
common case.
When building the compiler, for example, it looks like ~95% of arguments
to `normalizePath` do not require any normalization.
* Check normalization before and after . cleanup
* Also cleanup leading ./
* support QualifiedName when narrowing inside loops
* add test
* narrow more qualified names
* handle `undefined` of `getFlowCacheKey `
* update comments in test
* Make normalizeSlashes a no-op there are no bad slashes
On Windows, there will probably be a negligible slowdown, iterating over
the pre-slash prefix of each unnormalized path (though we might come out
ahead if paths are normalized more than once).
On *nix, this saves work - 1.8s -> 0.4s in the project I'm
investigating.
* Reuse already-computed index
* Everything mostly works
A couple of mixed, nested references don't work yet.
The scanner+parser interaction is wrong, the parser consumes one too
many spaces, and the checker+services code needs a little cleanup.
* Cleanup
1. I decided that correctly parsing a#b.c, an entity name containing an
instance reference, is not worth the work.
2. I made the scanner, at least the jsdoc part, emit a # token, and
provided a reScanPrivateIdentifier in order to convert #a to # a.
3. I cleaned up the code in the checker.
2. Unrelated: I added a missing space in linkPart display.
* Cleanup lint + var naming
* investigate+clean up a couple of TODOs
* Fix lint in utilities.ts
* change name to JSDocMemberName
* address PR comments
* Private identifiers use standard identifer scanning
Previously they used an old copy of the identifier scanning code that
didn't handle extended unicode yet.
* gotta fix that const lint
