maxmustermann/TypeScript
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity
TypeScript/tests/cases/conformance/jsdoc/jsdocTypeReferenceToMergedClass.ts

16 lines
336 B
TypeScript
Raw Normal View History

Restore delayed merge check to getTypeFromJSDocValueReference (#34706) * Restore delayed merge check to getTypeFromJSDocValueReference This is needed when a function merges with a prototype assignment. The resulting *merged* symbol is a constructor function marked with SymbolFlags.Class. However, the merge doesn't happen until getTypeOfFuncClassEnumModule is called, which, in the getTypeReferenceType code path, doesn't happen until getTypeFromJSDocValueReference. That means the check for SymbolFlags.Class is missed. Previously, getTypeFromJSDocValueReference had a weird check `symbol !== getTypeOfSymbol(symbol).symbol`, which, if true, ran getTypeReferenceType again on `getTypeOfSymbol(symbol).symbol`. For JS "aliases", this had the effect of dereferencing the alias, and for function-prototype merges, this had the effect of ... just trying again after the merge had happened. This is a confusing way to run things. getTypeReferenceType should instead detect a function-prototype merge, cause it to happen, and *then* run the rest of its code instead of relying on try-again logic at the very end. However, for the RC, I want to fix this code by restoring the old check, with an additional check to make sure that #33106 doesn't break again: ```ts const valueType = getTypeOfSymbol(symbol) symbol !== valueType.symbol && getMergedSymbol(symbol) === valueType.symbol ``` I'll work on the real fix afterwards and put it into 3.8. * Add bug number
2019-10-24 18:24:58 +02:00
// https://github.com/microsoft/TypeScript/issues/34685
// @noEmit: true
// @allowJs: true
// @checkJs: true
Fix expando handling in getTypeReferenceType (#34712) * Fix expando handling in getTypeReferenceType getExpandoSymbol looks for the initialiser of a symbol when it is an expando value (IIFEs, function exprs, class exprs and empty object literals) and returns the symbol. Previously, however, it returned the symbol of the initialiser without merging with the declaration symbol itself. This missed, in particular, the prototype assignment in the following pattern: ```js var x = function x() { this.y = 1 } x.prototype = { z() { } } /** @type {x} */ var xx; xx.z // missed! ``` getJSDocValueReference had weird try-again code that relied on calling getTypeOfSymbol, which *does* correctly merge the symbols. This PR re-removes that code and instead makes getExpandoSymbol call mergeJSSymbols itself. * Remove extra newline
2019-10-24 22:12:44 +02:00
// @Filename: jsdocTypeReferenceToMergedClass.js
Restore delayed merge check to getTypeFromJSDocValueReference (#34706) * Restore delayed merge check to getTypeFromJSDocValueReference This is needed when a function merges with a prototype assignment. The resulting *merged* symbol is a constructor function marked with SymbolFlags.Class. However, the merge doesn't happen until getTypeOfFuncClassEnumModule is called, which, in the getTypeReferenceType code path, doesn't happen until getTypeFromJSDocValueReference. That means the check for SymbolFlags.Class is missed. Previously, getTypeFromJSDocValueReference had a weird check `symbol !== getTypeOfSymbol(symbol).symbol`, which, if true, ran getTypeReferenceType again on `getTypeOfSymbol(symbol).symbol`. For JS "aliases", this had the effect of dereferencing the alias, and for function-prototype merges, this had the effect of ... just trying again after the merge had happened. This is a confusing way to run things. getTypeReferenceType should instead detect a function-prototype merge, cause it to happen, and *then* run the rest of its code instead of relying on try-again logic at the very end. However, for the RC, I want to fix this code by restoring the old check, with an additional check to make sure that #33106 doesn't break again: ```ts const valueType = getTypeOfSymbol(symbol) symbol !== valueType.symbol && getMergedSymbol(symbol) === valueType.symbol ``` I'll work on the real fix afterwards and put it into 3.8. * Add bug number
2019-10-24 18:24:58 +02:00
var Workspace = {}
Fix expando handling in getTypeReferenceType (#34712) * Fix expando handling in getTypeReferenceType getExpandoSymbol looks for the initialiser of a symbol when it is an expando value (IIFEs, function exprs, class exprs and empty object literals) and returns the symbol. Previously, however, it returned the symbol of the initialiser without merging with the declaration symbol itself. This missed, in particular, the prototype assignment in the following pattern: ```js var x = function x() { this.y = 1 } x.prototype = { z() { } } /** @type {x} */ var xx; xx.z // missed! ``` getJSDocValueReference had weird try-again code that relied on calling getTypeOfSymbol, which *does* correctly merge the symbols. This PR re-removes that code and instead makes getExpandoSymbol call mergeJSSymbols itself. * Remove extra newline
2019-10-24 22:12:44 +02:00
/** @type {Workspace.Project} */
var p;
p.isServiceProject()
Restore delayed merge check to getTypeFromJSDocValueReference (#34706) * Restore delayed merge check to getTypeFromJSDocValueReference This is needed when a function merges with a prototype assignment. The resulting *merged* symbol is a constructor function marked with SymbolFlags.Class. However, the merge doesn't happen until getTypeOfFuncClassEnumModule is called, which, in the getTypeReferenceType code path, doesn't happen until getTypeFromJSDocValueReference. That means the check for SymbolFlags.Class is missed. Previously, getTypeFromJSDocValueReference had a weird check `symbol !== getTypeOfSymbol(symbol).symbol`, which, if true, ran getTypeReferenceType again on `getTypeOfSymbol(symbol).symbol`. For JS "aliases", this had the effect of dereferencing the alias, and for function-prototype merges, this had the effect of ... just trying again after the merge had happened. This is a confusing way to run things. getTypeReferenceType should instead detect a function-prototype merge, cause it to happen, and *then* run the rest of its code instead of relying on try-again logic at the very end. However, for the RC, I want to fix this code by restoring the old check, with an additional check to make sure that #33106 doesn't break again: ```ts const valueType = getTypeOfSymbol(symbol) symbol !== valueType.symbol && getMergedSymbol(symbol) === valueType.symbol ``` I'll work on the real fix afterwards and put it into 3.8. * Add bug number
2019-10-24 18:24:58 +02:00
Workspace.Project = function wp() { }
Workspace.Project.prototype = {
isServiceProject() {}
}
Reference in a new issue Copy permalink