Conversation
src/compiler/emitter.ts
Outdated
| } | ||
|
|
||
| function writeSignificantLine() { | ||
| // writer.flush(); |
There was a problem hiding this comment.
Should either comment on why there's commented out code here or remove it.
There was a problem hiding this comment.
This should be removed.
src/compiler/sourcemap.ts
Outdated
| && typeof x.file === "string" | ||
| && typeof x.mappings === "string" | ||
| && isArray(x.sources) && every(x.sources, isString) | ||
| && (x.sourceRoot === undefined || typeof x.sourceRoot === "string") |
There was a problem hiding this comment.
Shouldn't we handle if sourceRoot === null? Same for sourcesContent and names?
There was a problem hiding this comment.
I don't think null is legal per the spec, but we can be more permissive.
There was a problem hiding this comment.
I'd rather make a best effort to parse a variety of bad sourcemaps than stubbornly refuse some almost correct ones.
| return x !== null | ||
| && typeof x === "object" | ||
| && x.version === 3 | ||
| && typeof x.file === "string" |
There was a problem hiding this comment.
While version and file are technically required in the spec.... we don't use them, and we don't need them to be present to handle a map correctly. Do we really need to check for them?
There was a problem hiding this comment.
Its a small enough test on a non-hot code-path, and I'd prefer to align with the spec here.
src/jsTyping/types.ts
Outdated
| @@ -1,4 +1,3 @@ | |||
| /* @internal */ | |||
There was a problem hiding this comment.
Yes. Otherwise we get test failures for our Public API tests after building tsserverlibrary.d.ts.
There was a problem hiding this comment.
Are these types supposed to be public (on master the library build is borked and including all private types)? This comment implies not...
There was a problem hiding this comment.
They actually were public prior to the change to use project references:
https://github.com/Microsoft/TypeScript/blob/release-2.7/lib/tsserverlibrary.d.ts#L4845
There was a problem hiding this comment.
Huh. OK. I guess we should ask Ryan if he intended to make them private or not.
There was a problem hiding this comment.
I think the issue is that they weren't "public" in typescriptServices.d.ts/typescript.d.ts, but they are "public" in tsserverlibrary.d.ts. Unfortunately, we can't make a file conditionally internal.
@RyanCavanaugh - What's the best course of action here?
There was a problem hiding this comment.
So the jsTyping file now contributes to the services build? Huh. I imagine it should be public then, considering they were already public in the server library; unless we've got a good reason to keep it private (at which point it should be private in both).
| @@ -1,21 +1,29 @@ | |||
| /*! ***************************************************************************** | |||
There was a problem hiding this comment.
The comments in this file are now gone... except for the copyright header, which is now here. Seems wrong?
| var a=0,b,{c}=obj,[d]=obj;let e=0,f,{g}=obj,[h]=obj; | ||
| //# sourceMappingURL=variables.js.map//// [for.js] | ||
| for(;;){} | ||
| //# sourceMappingURL=for.js.map//// [embeddedStatement.js] |
There was a problem hiding this comment.
Hm. There's no tailing newline in the file, which is the goal, but this baseline is ugly because there's now a //// header on the same line as the last line as the prior file.
There was a problem hiding this comment.
We weren't previously emitting a trailing newline after the source map comment. You can see this in existing baselines like jsxFactoryIdentifier.js, jsxFactoryQualifiedName.js, etc. We could probably fix this, but I wanted to avoid unrelated baseline changes.
There was a problem hiding this comment.
:( we should open an issue to track it.
There was a problem hiding this comment.
I'll just go ahead and fix it.
|
@sandersn Should be smaller now with the build script changes pulled out. |
sandersn
left a comment
There was a problem hiding this comment.
Looks fine as far as I could understand it with one reading. Maybe tomorrow I can sit down with you to learn some higher-level concepts to do with emitting and source maps.
| @@ -61,11 +61,10 @@ namespace ts { | |||
| let str = ""; | |||
There was a problem hiding this comment.
not worth fixing as part of this PR, but utilities is a weird place for creating EmitTextWriters. Seems pretty specialised.
src/compiler/sourcemap.ts
Outdated
| let nameToNameIndexMap: Map<number> | undefined; | ||
|
|
||
| // Last recorded and encoded mappings | ||
| let generatedLine = 0; |
There was a problem hiding this comment.
It's a bit confusing seeing a lot of references to generatedLine, sourceIndex, etc even though most are to locals, not to these closed-over declarations. Maybe another prefix to contrast with 'pending-' would help?
src/compiler/sourcemap.ts
Outdated
| } | ||
|
|
||
| enter(); | ||
| Debug.assert(pendingGeneratedCharacter >= 0, "lastRecordedGeneratedCharacter was negative"); |
There was a problem hiding this comment.
I don't understand how the assert text relates to the assertion.
|
@weswigham if you have time can you take another look? |
mhegazy
left a comment
There was a problem hiding this comment.
@weswigham can you take another look.
|
@mhegazy should I wait on @weswigham or merge? |
|
go for it. |
|
@DanielRosenwasser indicated we might want to wait on this a bit longer. I'll hold off on merging until we can discuss. |
|
Just one comment about the remove whitespace output: By it's nature, it is very hard to read (I'm pretty sure I just glossed over the new output baselines). It would be best if we could verify that they still behave as expected post-de-whitespacing. It's not necessary, strictly speaking, but just like with helper changes, these are exactly the kind of emit-related changes that actually validating the runtime behavior of the generated code seems useful to me. Just another remark for the technical backlog~ ❤️ |
|
This experiment is pretty old, so I'm going to close it to reduce the number of open PRs. |
This PR adds a
--removeWhitespacecompiler switch that affects JavaScript output only. When enabled, any insignificant whitespace (along with any insignificant trailing semicolon characters) is elided from the output.Whitespace is considered significant in the following cases:
+and++and++-and--and--Semicolons are considered insignificant in the following cases:
;before then end of a block (}), except when part of an embedded statement (i.e.{while(true);});;), except when in the head of aforloop (i.e.for(;;))