* Add tests for "Cannot find name 'global'. Did you mean 'global'?"
* Fix "Cannot find name 'global'. Did you mean 'global'?"
* Add an additional test case for spelling suggestions of "global".
* Name the boolean for suggestions being global scope augmentations.
* chore: failing test for const enums and isolatedModules
* fix: const enums + isolatedModules emit invalid code
In `isolatedModules` mode, the compiler does not inline const enums,
but also decides not to `import` them, leaving invalid code that
throws a `ReferenceError` at runtime.
This code:
```
import { SomeEnum } from './bar';
sink(SomeEnum.VALUE);
```
..should compile to either:
```
var { SomeEnum } = require('./bar');
sink(SomeEnum.VALUE);
```
..or (with const enum inlining):
```
sink(1 /* VALUE */);
```
..but actually compiles to:
```
sink(SomeEnum.VALUE);
```
..with no imports, which throws a ReferenceError at runtime.
---
The compiler has already realised that the symbol is a referenced const
enum, it just doesn't use this information when it comes to deciding
whether to emit an import. This commit additionally checks that
information, if we are compiling in isolatedModules mode.
---
In my opinion, this is not the correct fix, but it is the simplest. In
`isolatedModules` mode, `const enum` should probably be a compile error
(because there are no benefits and the complexity is high, and,
apparently, buggy). If not, the compiler should not be checking whether
something is a const enum, and should just be treating it as a regular
enum, and checking as if it was?
Fixes#40499.
* chore: extra test for type-only
* feat: explicitly ban --isolatedModules --preserveConstEnums false
* feat: isolatedModules implies preserveConstEnum
* Update src/compiler/diagnosticMessages.json
Co-authored-by: Andrew Branch <andrewbranch@users.noreply.github.com>
* chore: compiler test for argument incompatibility
* Add and fix test for namespace import of const enum
* Fix additional bug with reexport of const-enum-only module
Co-authored-by: Andrew Branch <andrewbranch@users.noreply.github.com>
Co-authored-by: Andrew Branch <andrew@wheream.io>
* 'in' should not operate on primitive types
* accept baselines of failing tests
* review
* update error message
* check if constraint of right type is assignable to a non primitive or instantiable non primitive
* do not throw errors where narrowing is impossible
* accept baselines
* fix test case failures
* Add more accurate comment discussion and document failing edge case in test
* Update baselines
Co-authored-by: Jonas Hübotter <jonas.huebotter@gmail.com>
* fix as suggestion.
* Update moduleSpecifiers.ts
* compare symbol rather than string
* fix typo.
* fix
* fix lint.
* better name and more clear code
* fix comment.
Co-authored-by: Orta Therox <git@orta.io>
* Have signature identity checks look at the base constraint of type parameters, allow identical type parameter lists to merge in union signatures
* Update text in fourslash test
* Add whitespace to fix lint, remove duplicate impl
* Consolidate names
* Remove comparisons of type parameter defaults, add more test cases
* Explore at least 10 levels of constraints before checking for deeply nested types
* Simplify constraint depth limiter logic
* Add regression test
* Accept new baselines
Fixes#41586Fixes#41588
1. For binary expressions, if the immediate parent is an IfStatement,
then check the body of the if statement. I didn't walk upward to find an
IfStatement because in my experimentation I found that binary expression
uncalled-function errors are only issued when the expression is on the left of the
top-most binary expression.
2. For property accesses with interspersed calls, I added a
CallExpression case. In fact, any expression could appear here, but I
only want to fix calls for now since that's all we've observed in
Definitely Typed, and we didn't see anything else in the user tests or RWC
tests. I also didn't examine parameters of the intermediate call
expressions, but I don't think it's needed since the intent is to avoid
false positives.
* Add actual baselines for a problem with global namespace being preferred over config & pragma implicit ones
* Fixed an issue with global React namespace being preferred over config & pragma implicit ones
* Do not try to mark JSX classic runtime symbols as used when automatic runtime is used
* Add tests
* Dont look at object or function type when looking for members of `export=` type to be resolved by named imports
Fixes#37165
* Create separate cache when skipping function and object property augmentation
* Lookup in both cache if not skipObjectFunctionPropertyAugment
* Support xml namespace prefix for JSX elements and attributes
Just as with the `-` character, `:` is now also treated specially in JSX
element and attribute names, but is only allowed a single time, and not
at the beginning or end of the name, as is specified in the JSX spec.
All tests in jsxInvalidEsprimaTestSuite still fail, but for slightly
different reasons now. Two lines in jsxEsprimaFbTestSuite were
uncommented as they included elements with namespaces, and they now pass
without error.
* Add case for colons at ends of identifier
* Add case for jsx namepsace intrinsics
* Add cases with upcase idents for jsx namespaces
* Add case for jsx namespaces with react option
* Always consider jsx names with colon to be intrinsics
* Adjust comment about chars valid in jsx names but not js idents
* Fix minor typo in namespace prefix test case variable name
* Remove misleading comments on isUnhyphenatedJsxName
* Use ts.map for stylistic consistency
* Show error only if noImplicitAny is set
* Accept baseline for noImplicitAnyIndexing
* Fix lint error
* Add test cases for indexedAccessWithFreshObjectLiteral
