TypeScript error reported in invalid filename (output parsing error?)

[DanTup]

I've seen this quite a lot these last few days; sometimes I get an error where the filename is completely messed up and if I click on the error in the problems window I then get an error that the file doesn't exist (with the path also being messed up - including parts of the error message inside the filename):

I'm not sure whether this is coming from built-in stuff or TSLint (since that seems to have some wonky behaviour) so I thought I'd start here and I can re-raise there if you think it's that.

[mjbvz]

Are you using tasks to build or watch your files?

[DanTup]

I think so - here's my tasks.json:

https://github.com/Dart-Code/Dart-Code/blob/master/.vscode/tasks.json

I also have the tslint extension installed.

[egamma]

@DanTup the error message is from the TypeScript compiler. It looks like the $tsc-watch problem matcher used in your task.json doesn´t match the compiler error correctly

What TypeScript version are you using?

I'm not sure whether this is coming from built-in stuff or TSLint (since that seems to have some wonky behaviour) so I thought I'd start here and I can re-raise there if you think it's that.

Just curious what the ´wonky TSLint behaviour´ is, can you please file an issue about this in https://github.com/Microsoft/vscode-tslint/issues

[DanTup]

I'm on TS 2.7.1 (I think it's the latest, though I think I was seeing this just before I most recently upgraded).

Relevant files here:

https://github.com/Dart-Code/Dart-Code/blob/master/package.json
https://github.com/Dart-Code/Dart-Code/blob/master/.vscode/tasks.json

The TSLint thing is ignored files randomly showing up in the problems window (opening/closing the file is enough to make them go away). I've opened https://github.com/Microsoft/vscode-tslint/issues/325.

[dbaeumer]

@DanTup this indeed looks like a problem with the matcher. For some reason it detects the end message of a the compile as a problem.

If this happens again can you post the output of the terminal running the tsc compile here. It is the terminal containing the task you started. There must be something wrong with that output since the normal matching works for me.

[vscodebot]

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.

Happy Coding!

[DanTup]

@dbaeumer Happened again - here's the error shown in the terminal:

> Executing task: npm run watch <


> dart-code@2.10.0-dev watch M:\Coding\Applications\Dart-Code
> tsc -watch -p ./
11:45:21 - Compilation complete. Watching for file changes.
ble to type 'TreeItem'.
  Types of property 'resourceUri' are incompatible.
    Type 'string' is not assignable to type 'Uri'.
src/views/packages_view.ts(38,18): error TS2339: Property 'depPath' does not exist on type 'PackageDep'.
src/views/packages_view.ts(41,37): error TS2339: Property 'depPath' does not exist on type 'PackageDep'.
src/views/packages_view.ts(42,42): error TS2339: Property 'depPath' does not exist on type 'PackageDep'.
src/views/packages_view.ts(122,7): error TS2415: Class 'PackageDep' incorrectlyextends base class 'TreeItem'.
  Types of property 'resourceUri' are incompatible.    Type 'string' is not assignable to type 'Uri'.
11:47:35 - Compilation complete. Watching for file changes.
src/views/packages_view.ts(51,36): error TS2345: Argument of type 'string' is not assignable to parameter of type 'Uri'.
src/views/packages_view.ts(101,46): error TS2345: Argument of type 'string' is not assignable to parameter of type 'Uri'.11:47:54 - Compilation complete. Watching for file changes.
11:48:54 - File change detected. Starting incremental compilation...
11:48:54 - Compilation complete. Watching for file changes.

Here's how the output looks if I do npm run compile:

M:\Coding\Applications\Dart-Code [master ≡ +0 ~1 -0 !]> npm run compile

> dart-code@2.10.0-dev compile M:\Coding\Applications\Dart-Code
> tsc -p ./

src/views/packages_view.ts(38,18): error TS2339: Property 'depPath' does not exist on type 'PackageDep'.
src/views/packages_view.ts(41,37): error TS2339: Property 'depPath' does not exist on type 'PackageDep'.
src/views/packages_view.ts(42,42): error TS2339: Property 'depPath' does not exist on type 'PackageDep'.
src/views/packages_view.ts(45,36): error TS2345: Argument of type 'string' is not assignable to parameter of type 'Uri'.
src/views/packages_view.ts(51,36): error TS2345: Argument of type 'string' is not assignable to parameter of type 'Uri'.
src/views/packages_view.ts(101,46): error TS2345: Argument of type 'string' is not assignable to parameter of type 'Uri'.
npm ERR! code ELIFECYCLE
npm ERR! errno 2
npm ERR! dart-code@2.10.0-dev compile: `tsc -p ./`
npm ERR! Exit status 2
npm ERR!
npm ERR! Failed at the dart-code@2.10.0-dev compile script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     C:\Users\danny\AppData\Roaming\npm-cache\_logs\2018-03-06T11_52_26_635Z-debug.log
M:\Coding\Applications\Dart-Code [master ≡ +0 ~1 -0 !]>

I've taken a copy of my working directory so hopefully can repro later if you need any more info than the above.

[dbaeumer]

Reopening.

@DanTup does that happen always. Looks to me if the output of the npm run watch command is broken / incorrect. How would a normal output look like?

[DanTup]

Hmm, this looks ok?

15:09:26 - Starting compilation in watch mode...

src/views/packages_view.ts(38,18): error TS2339: Property 'depPath' does not exist on type 'PackageDep'.
src/views/packages_view.ts(41,37): error TS2339: Property 'depPath' does not exist on type 'PackageDep'.
src/views/packages_view.ts(42,42): error TS2339: Property 'depPath' does not exist on type 'PackageDep'.
src/views/packages_view.ts(45,36): error TS2345: Argument of type 'string' is not assignable to parameter of type 'Uri'.
src/views/packages_view.ts(51,36): error TS2345: Argument of type 'string' is not assignable to parameter of type 'Uri'.
src/views/packages_view.ts(101,46): error TS2345: Argument of type 'string' is not assignable to parameter of type 'Uri'.
15:09:29 - Compilation complete. Watching for file changes.

Though looking back at the errors, I wonder if I copied my code after I'd already fixed an error, since the "half printed" error doesn't seem to be there.

[DanTup]

Not sure if this helps any more, but just hit it again and noticed that the error was actually from 10 minutes earlier - I guess I only noticed it when I went to click on the item in the errors pane:

[DanTup]

I might have bee slightly wrong about how often this happens; I've hit it 5 or 6 times this afternoon! :(

[dbaeumer]

I have no idea yet why this is happening. It is clear that the file name is incorrectly parsed from the output but I was not able to spot these in the output you provided. Which version of tsc are you using. I am asking since in 2.7.x tsc introduce escape sequences to clear the screen and may be this breaks something.

Do you think this is something I could reproduce if you share your source code.

[DanTup]

@dbaeumer The project is https://github.com/Dart-Code/Dart-Code. I don't have source that reliably repros this, since it's usually only well after the error occurred that I noticed it, but it might show the versions etc.

I think I have been on ts v2.7.2 for a while, so that sounds like a possibility.

[DanTup]

This is weird - I have a perfect repro of this... I can restart Code, open the folder, hit Ctrl+Shift+B and get a single error with this issue.

However, I copied the folder, cleaned out out/node_modules etc. to make it smaller to upload, then tried to repro there by doing npm install and then opening. Doesn't happen. Still happens in my original. Makes no sense :(

Digging...

[DanTup]

Ok, maybe I have it! Do you have to do detection of when things wrapped? The only difference between the two folders I have mentioned above are the paths. I ran npm run watch in both folders and her's the output:

Of course it's the same except for the paths. The only thing I can guess, is that it's because the broken one ends one error on the last character of the line - so if you were trying to guess whether a line wrapped or not, maybe it's failing here?

(If not, I'm out of ideas :))

[DanTup]

Of course, since I posted this the issue has totally gone away again! (╯°□°）╯︵ ┻━┻)

[dbaeumer]

OK. I know why the second one breaks. It is because under Windows the terminal uses some magic to reconstruct lines in the terminal due to the lack of API under Windows. So the two error lines are folded into one hence making the problem detector fail.

To fix this I need more cooperation from the terminal.

@Tyriar what about I give you a hint in form of a regexp when to keep the next line separate even if the line before occupies the whole width? Alternatively we can give up on doing this in the terminal and the problem matcher does this. But I would need to know the width and I have no good understanding what would happen under Linux / Mac.

[vscodebot]

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.

Happy Coding!

[DanTup]

@dbaeumer This was closed by the bot because of the needs-more-info tag.

[dbaeumer]

@Tyriar different question: with the new terminal work for Windows will this problem go away?

[Tyriar]

@dbaeumer microsoft/node-pty#216 is expected to improve this situation, but it may do the same thing as winpty in this regard and move the cursor to the next line instead of relying on the terminal.

@zadjii-msft when a line is expected to wrap in conpty do you move the cursor down or rely on the terminal emulator to fix it, and therefore allow it to track full unwrapped lines?

[zadjii-msft]

I believe I prototyped something like this for RS5, but it broke something else near the end of the release cycle and pulled it at the last minute. It was a little tricky to get exactly right without more test applications. So in RS5, we break text manually with a "\r\n".

I'm happy to take another look at not manually breaking lines in this upcoming release. I've filed MSFT:19012792 on myself to investigate more :)

[dbaeumer]

@Tyriar moving the cursor is not an issue for me. The problem is that even though the program printed one line to stdout there is no reliable way right now to reconstruct that line. So just to be sure: in the future this will not be an issue anymore.

[Tyriar]

@dbaeumer what I'm hearing from @zadjii-msft:

So in RS5, we break text manually with a "\r\n".

In RS5 it will still be an issue as the pty wraps text, xterm.js needs to receive the unwrapped text in order for it to know reliably where the wrapping points are.

[ncannasse]

Just to add a few additional comments on this issue:

• it is very problematic to have compiler errors length as captured by problemMatcher limited by the terminal width (see Terminal tasks cannot be processed by problemMatcher #62914) . A good workaround would be to allow tasks to be run outside of a terminal, instead directly spawn a process which will not have specific line width.

• additionally, the terminal original size of 80 is kept until you navigate to the "Terminal" tab, which makes it even more problematic since some workflow use reveal:never and only stay on "Problems" tabs.

[ncannasse]

@dbaeumer what kind of Windows API would you need to dewrapping the lines correctly ? There is a way to detect the terminal width, according to https://gist.github.com/jtriley/1108174

[dbaeumer]

@ncannasse this is not a width issue and not an issue with 80 characters. It is about the fact that if a line ends with a space in the terminal we don't know under Windows whether the next line belongs to it or not. With the current API we have to guess :-).

We had a separate process before and this cases another big set of problems especially around ANSI escape sequences. So going back to this is not an option.

To my knowledge you work on a language server. Why to do rely on tasks to produce the errors. You can always create diagnostics directly using the VS Code API?

[Gama11]

To my knowledge you work on a language server. Why to do rely on tasks to produce the errors. You can always create diagnostics directly using the VS Code API?

I'm not quite sure how that's related, a language server doesn't handle tasks / compilation. And as far as I know, VSCode currently doesn't have an API to "intercept" the execution of a task to allow for diagnostics-based problem reporting.

[ncannasse]

@dbaeumer correct me if I'm wrong but diagnostics apply to currently opened files, whereas compilers can report issues in closed files.

[dbaeumer]

@ncannasse no, diagnostics are for both open and closed files.

[alexr00]

RE this:

So in RS5, we break text manually with a "\r\n".

In RS5 it will still be an issue as the pty wraps text, xterm.js needs to receive the unwrapped text in order for it to know reliably where the wrapping points are.

It looks like the problem is that a line break that tsc is adding isn't staying added on Windows. Here it sounds like line breaks will be manually added with \r\n. If the line break intended by tsc is preserved, then the problem matcher should still work.

@Tyriar, am I understanding this correctly?

[Tyriar]

@alexr00 this comment gives some more details:

https://github.com/xtermjs/xterm.js/blob/f98572cf7173b2a78d762fe75c918d1a84690e3b/src/addons/winptyCompat/winptyCompat.ts#L22-L40

Basically conpty and winpty will always sent \r\n instead of just a \r for a wrapping line, which means xterm.js gets 0 wrapped lines. So the above is used to assume that any line that has a character in the final cell will wrap to the last which fixes the majority of cases (performs better the wider a terminal is).

[alexr00]

I see, thank you.

[dkuschmierz]

Hi, I also have the problem with the problemMatcher while using Clang-Tidy in our project. Will there be a fix in one of the nearer VSCode updates or can I fix it by my own?

[Tyriar]

Here's the tracking issue for ConPTY that we need to get this fixed properly microsoft/terminal#405

[Tyriar]

There is nothing further we can action here so I'm closing it in favor of the upstream microsoft/terminal#405 which would fix the problem.