* Fix error term of declaration in modules
* fix test
* change error code of "An import declaration can only be used at the top level of a module."
* Separate js and ts files for export errors in module.
* Change non-top-level error in namespace
* format
Co-authored-by: Nathan Shively-Sanders <293473+sandersn@users.noreply.github.com>
* WIP: pass in checkmode to getNarrowableTypeForReference
* add tests
* another pass through new check mode argument
* rename new check mode
* only use rest flag for rest elements in objects
* add and update tests
* change check mode flag name
* restore package-lock.json
* fix comments
* get rid of fourslash tests
* fix caching in checkExpressionCached when checkMode is not normal
* Don't distinguish between object and array rest elements
* get rid of undefined check mode
* don't make includeOptionality into checkmode flag
1. During name resolution, `@param` and `@return` tags should walk up
through the jsdoc comment and then jump to the host function. Previously they
did not, which would cause them to not resolve type parameters bound in
the scope of a host that was not a sibling of the comment. The example
from #46618 is a prototype method:
```js
/**
* @template {T}
* @param {T} t
*/
C.prototype.m = function (t) {
}
```
2. During name resolution, prototype methods are supposed to resolve
types both from the host function's location and from the containing
class' location. The containing class lookup happens in a separate call
to `resolveName`. Previously, the code that finds the containing class
only worked for the above style of comment, which is on the outer
ExpressionStatement, but not for the below style, which is on the
function expression itself:
```js
C.prototype.m =
/**
* @template {T}
* @param {T} t
*/
function (t) {
}
```
* Fix @link https:// formatting
Also improve .d.ts formatting of `@link`,`@linkcode`,`@linkplain`.
Fixes#46734
1. Previously, `@link` incorrectly put a space between "https" and "://"
when formatting jsdoc for editors. Now it does not.
2. When fixing the same output for .d.ts, I discovered that all `@link` tags
were formatted as `@link`, even if they were `@linkcode` or
`@linkplain`. I fixed that too.
* semicolon lint
* Fix inlay hint crash for jsdoc function type syntax
Parameters in JSDoc function types do not have names. The type does not
reflect this. This PR fixes the crash; I'll see how much churn it causes
to fix the type as well.
Fixes#47606
* make inlay hints test smaller
* Fix duplicate completions from two different copies of a node_modules package
* Fix logic for scoped packages
* Fix errors from merge
* Less gross way to reconcile these two conflicting PRs
* Import fix
* Wire up completions, add sorting to fix
* Fix overlapping changes when there’s only one import specifier
* Update API baseline
* Add sorting and filtering back to UMD fix
* Allow structure reuse if a declaration file within a package is updated
Closes#47471
* Use correct program to obtain source file in structure reuse test
Walking up the tree to find the enclosing SourceFile would distort the
timing too much so, instead, we attach a Path in the binder.
At present, the path is determined retroactively by walking up the call
stack in the trace visualizer, but this is both inconvenient and
routinely inaccurate (checking an expression in one file may require
checking an expression in another file and there's no way to determine
from the trace where this transition occurred).
This removes a few places where global compiler bindings are mutated:
1. Make `sysLog` call an internal binding which is changed via
`setSysLog`.
2. Use `Object.assign` to change values *in* `objectAllocator` instead
of mutating the binding itself. (The type should verify that any
future uses of this will properly override all bindings.)
3. `localizedDiagnosticMessages` is not really needed as an exported
value, there's only one place that uses it to test whether it is set
or not. So drop the export and replace it with a new
`maybeSetLocalizedDiagnosticMessages` (internal) function.
* Use relative paths for the end of compile report
* Have a tighter suffix for multiple errors in one file
* Review feedback
* Refactors, and adds color
* Update baselinies
* Use package.json cache in module specifier generation
* Let AutoImportProviderProject reuse module resolution cache of host project
* Add missing module resolution cache access, add logging to getRootFileNames
* Reuse packageJsonImportFilter
* Only log when the project will be created, update API baseline
* Remove override that could mess up watches
* Allowed non-this, non-super code before super call in derived classes
Fixes#8277.
It feels wrong to put a new `forEachChild` loop in the checker, though in the vast majority of user files this will be a very quick one. Is there a better way to check for a reference to `super` or `this`?
* Used new isNewThisScope utility and dummy prop in baselines
* Accounted for parameters and get/set accessor bodies
* Accounted for class extensions
* (node|statement)RefersToSuperOrThis wasn't checking root level scope boundaries
```ts
function () {
return this;
}
```
It was immediately going to `ts.forEachChild` so the statement itself wasn't being counted as a new `this` scope.
* Better 'references' name and comments; accounted for more method edge case
* Limited super calls to root-level statements in constructor bodies
As per discussion in the issue, it would be ideal to consider any block that always ends up calling to super() the equivalent of a root-level super() statement. This would be valid:
```ts
foo = 1;
constructor() {
condition() ? super(1) : super(0);
this.foo;
}
```
...as it would compile to the equivalent of:
```ts
function () {
condition() ? super(1) : super(0);
this.foo = 1;
this.foo;
}
That change would a bit more intense and I'm very timid, so leaving it out of this PR. In the meantime the requirement is that the super() statement must itself be root-level.
* Fixed error number following 'master' merge
* Added decorator test cases
* Again allowed arrow functions
* Accepted new baselines
* Added allowance for (super())
* Reworked emitter transforms for ES this binding semantics
In trying to adjust to rbuckton's PR feedback, this orders derived class constructor bodies into five sections:
1. Pre-`super()` code
2. The `super()` call itself
3. Class properties with initializers
4. Parameter properties
5. The rest of the constructor
I've looked through the updated baselines and it looks like they're generally better than before. Within the existing test cases that result in semantic errors for `this` access before `super`, several previously resulted in a global `_this` being created; now, they correctly defer referring to `_this` until it's assigned to `_super.call(this) || this`.
* Used skipOuterExpressions when diving for super()s; fix prop ordering
* Allow direct var _this = super() when no pre-super() statements; lint fixes
* Always with the TSLint
* One last touchup: skipOuterExpressions in es2015 transformer
* Fixed new lint complaint in utilities.ts
* Again added a falls-through; it'd be swell if I could run linting locally
* This time I think I got it
* Well at least the error is a different one
* Undid irrelevant whitespace changes
* Mostly addressed private/field issues
* Accepted derivedClassSuperProperties baseline
* Lint fix, lovely
* Remove now-unnecesary comment
* First round of feedback
* Moved prologue statements to start of statements
* Added consideration for super statements in loops and the like
* Ordering and a _this_1 test
* Missed the one change I needed...
* First round of feedback corrections
* Feedback round two: statements
* Feedback: used more direct statements
* Fixed classFields emit to not duplicate temp variables
* Refactored es2015 helper to be less overloaded
* Accounted for parentheses
* Simpler feedback: -1, and emptyArray
* Next feedback: superStatementIndex
* Feedback: simplified to no longer create slice arrays
* Adjusted for default and rest parameters
* Added test case for commas
* Corrected comment ranges
* Handled comments after super, with tests
* Fixed Bad/Late super baselines
* Remove unused param and unnecessary baseline comments
Co-authored-by: Orta Therox <orta.therox@gmail.com>
Co-authored-by: Ron Buckton <ron.buckton@microsoft.com>
When the binding is itself one that was created by `__createBinding`,
re-use its descriptor, which avoids piling multiple levels of getters in
the case of multiple levels of exports.
In addition, reuse a descriptor if the bindings is marked as
non-writable and non-configurable, which makes a getter not
necessary. (This can be done manually if needed, even though tsc
doesn't do it now.)
Also related to #46744 and to microsoft/tslib#165.
* Avoid printing comments on static fields twice.
In TS4.4, when a transformer adds a static field with a synthetic
comment to a decorated class, TS prints the synthetic comment twice:
@Decorator
class MyClass {
/* comment */ staticField = 'x'; // field and comment added by transformer
}
Becomes:
var MyClass = class MyClass {}
/*comment*/
/*comment*/
MyClass.newField = "x";
__decorate(MyClass, Decorator, ...)
This is because the classFields transformer calls `setOriginalNode(n,
propertyDeclaration)` on both the expression statement , and the
assignment expression contained in it, leading to the synthetic comment
appearing twice.
This change avoids the problem by explicitly deleting any synthetic
comments from the assignment expression created for static fields when
creating the expression statement containing the assignment. This allows
us to retain the information of the original node without printing the
synthetic comment twice.
* Update src/testRunner/unittests/transform.ts
Co-authored-by: Daniel Rosenwasser <DanielRosenwasser@users.noreply.github.com>
* Have auto-import provider pull in `exports`
* Revert filtering of node_modules relative paths, to do in separate PR
* Do @types and JS prioritization correctly
* Cache entrypoints on PackageJsonInfo
* Add one more test
* Delete unused function
* Fix other tests - dependencies need package.json files
* Do two passes of exports resolution
* Fix missed refactor
* Apply suggestions from code review
Co-authored-by: Nathan Shively-Sanders <293473+sandersn@users.noreply.github.com>
* Uncomment rest of test
* Handle array targets
Co-authored-by: Nathan Shively-Sanders <293473+sandersn@users.noreply.github.com>
* Type { [P in K]: E }[X] has constraint E with X substutited for P
* Add regression test
* Fix PragmaMap and ReadonlyPragmaMap declarations
* Explore additional constraint
* Revert previous change
* Add tests
