The following errors were reported by 5.5.0-dev.20240324
Pipeline that generated this bug
Logs for the pipeline run
File that generated the pipeline
This run considered 300 popular TS repos from GH (after skipping the top 0).
Successfully analyzed 292 of 300 visited repos
| Outcome | Count |
|---|
| Detected interesting changes | 5 |
| Detected no interesting changes | 287 |
| Unknown failure | 8 |
Investigation Status
| Errors | Repos | Outcome |
|---|
| Server exited prematurely with code unknown and signal SIGABRT | 1 | |
| Error: Debug Failure. Did not expect ObjectLiteralExpression to have an Identifier in its trivia | 1 | Deprioritizing investigation as the error shows for a minimized file and does not have a clear repro. |
| Error: Debug Failure. False expression. | 1 | CompletionInfo is failing due to the synthetic propertySignature is using an incorrect questionToken position, causing the Assert to fail. I noticed that there's two signatures with the same property name in different positions. I suspect that the second property, the one out of bounds of the range, is being assigned to the signature incorrectly.
Investigation: assignPositionsToNode is probably the culprit of the node not having the right position. We validated before that no positions are set. We do not know yet if it's because is reusing a node or is just assigning an incorrect value.
Fix on PR #58263 |
| Error: Debug Failure. Expected declaration to have at least one class-like declaration | 1 | Assigning a property its prototype caused definition to stop working. Minimal repro:const A ={};
A.B = class Foo {}
new A.|B|(); // <-- Go to definition here
A.B.prototype.C = null; // Comment this line and the issue do not repro.Investigation: Hypothesis is that on an expando object we're not looking into the right side of the assignment before getting to getConstructSignatureDefinition. Note: I don't understand why commenting out prototype causes it to work. If we do the symbol is no longer flag as a class so it doesn't hit the Debug.Fail.
Fix in PR #57628. |
| Error: Debug Failure. False expression: Expected the specifier to be a default export | 1 | Completions gets confused by processing a named export with the default version, causing the assert to be hit. See repro:// file1.js
const a = 1;
export {
a as b
};
export default a;
// file2.js
import * as foo from './file1';
| //<-- Trigger completions here
export default foo.b; Investigation: We're getting an alias for a default export, but why do we get an alias? (getDefaultExportInfoWorker) |
The following errors were reported by 5.5.0-dev.20240324
Pipeline that generated this bug
Logs for the pipeline run
File that generated the pipeline
This run considered 300 popular TS repos from GH (after skipping the top 0).
Successfully analyzed 292 of 300 visited repos
Investigation Status
Investigation: assignPositionsToNode is probably the culprit of the node not having the right position. We validated before that no positions are set. We do not know yet if it's because is reusing a node or is just assigning an incorrect value.
Fix on PR #58263
const A ={};Investigation: Hypothesis is that on an expando object we're not looking into the right side of the assignment before getting to getConstructSignatureDefinition. Note: I don't understand why commenting out prototype causes it to work. If we do the symbol is no longer flag as a class so it doesn't hit the Debug.Fail.A.B = class Foo {}
new A.|B|(); // <-- Go to definition here
A.B.prototype.C = null; // Comment this line and the issue do not repro.
Fix in PR #57628.