Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Same error is duplicated in Error List - with and without line breaks ... no, strike that last #6680

Closed
BentTranberg opened this issue May 3, 2019 · 5 comments

Comments

@BentTranberg
Copy link

BentTranberg commented May 3, 2019

I thought we already had an issue related to this, but I have searched, and apparently there isn't. It may be that what I almost remember is a comment somewhere from somebody on the Visual F# team about this. Maybe one to three years back. Anyway, it's a good time to fix it I think. Not that it's important.

The following will result in compile error FS0001 : This expression was expected to have type 'string' but here has type ''a option'

let s: string = Some "Hello"

In Visual Studio 2019, 16.0.2, the error is frequently reported twice in the Error List pane. At first I thought this was once from Intellisense and once from Build, and that IntelliSense produced the one with line breaks. And I thought the problem was perhaps that because one had breaks and the other not, they weren't identified as the same error. Now I've started digging, and I am not sure about anything anymore. It seems to be less consistent the more I try to reproduce the behavior. Have a look at these screenshots.

Build + IntelliSense

sshot-1

Build Only

image

The screenshot with and without line breaks I just can't get back at the moment, in spite of that being the norm. (Had to log in remote to my work machine to get an earlier screenshot.) The screenshot with two identical, and with only "Build", I only got once ever. Funny thing is that I had no problem reproducing the first frequently when I didn't really try - earlier today and yesterday. It's a variation of the "only on my machine" theme - ha ha.

Additional note

When I pasted the error message from VS Error List pane into here, there were characters displayed as square boxes inside the error message itself, at the positions where I would expect line breaks to be in the screenshot with line breaks. But the error message I copied came from the screenshot with two lines without breaks.

So now I did one more experiment. I pasted the error message with breaks. This resulted in no square boxes, but proper line breaks, just like in Visual Studio. Here you see it straight from VS:

This expression was expected to have type
'string'
but here has type
''a option'

My guess is that the boxes were LF only, while in the text above there are proper CR+LF. Or perhaps even the other way round.

Repro steps

Try with the code snippet, but don't expect reliable results.

@BentTranberg BentTranberg changed the title Same error is duplicated in Error List - with and without line breaks Same error is duplicated in Error List - with and without line breaks ... no, strike that last May 3, 2019
@cartermp cartermp modified the milestones: 16.2, Backlog May 13, 2019
@cartermp
Copy link
Contributor

Unfortunately, the error list has been a source of woes for F# tooling, especially w.r.t errors being "sticky" or duplicated.

@BentTranberg
Copy link
Author

BentTranberg commented May 13, 2019

Tell me about it! => #3510. There's a good repro there - for "sticky", not this one.

@dsyme
Copy link
Contributor

dsyme commented Aug 31, 2020

I can't specifically repro this using the information up above (though the bug report does say it is intermittent).

@dsyme
Copy link
Contributor

dsyme commented Aug 31, 2020

Give I can't repro, and we haven't had additional information on this thread for over 12 months, I will close.

That doesn't mean the bug isn't there. We it just means we need a definite repro to make progress

@dsyme dsyme closed this as completed Aug 31, 2020
@abelbraaksma
Copy link
Contributor

There was an issue that's meanwhile fixed, that caused this behavior when multi targeting different frameworks.

@cartermp cartermp removed this from the Backlog milestone Sep 1, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants