Wrong expression is ignored warning range

[auduchinok]

module ClassLibrary17

for i in 1 .. 10 do
    printfn ""
    printfn "" |> ignore
    123

The result of this expression has type 'int' and is implicitly ignored.
Consider using 'ignore' to discard this value explicitly, e.g. 'expr |> ignore', or 'let' to bind the result to a name, e.g. 'let result = expr'.

[abelbraaksma]

I doubt the error is wrong. The expression as a whole is marked and returns 123. This is not piped to ignore, so the warning is correct. Fix it by adding ignore either to each for subexpression, or to the for expression as a whole.

[auduchinok]

@abelbraaksma I expect the warning range to cover 123 only and not to account previous sequential expressions, the way it works in other places, e.g. in modules:

[TIHan]

I also expect the warning to show as @auduchinok described. The error does seem correct, but the range could be more accurate.

[abelbraaksma]

The error does seem correct, but the range could be more accurate.

@TIHan, @auduchinok, I agree that it is confusing, but if we want to improve the error reporting, we should define what we mean by "more accurate". The tricky bit here is, that the parser sees the body of the for as a whole expression. And there's nothing wrong of a for returning something, hence the whole expression is marked (and I'm surprised the for ... do is not marked itself). Since this is a do-expression, it must always return unit, so improving here should be a good thing.

The comparison with modules doesn't work, because that is not an expression as a whole.

Note that it does apply to other situations where an expression can be multiple lines:

Here with if, where the processor correctly underlines the whole expression:

Here with while...do, same as with for:

[edgarfgp]

So I have been looking into fixing some inaccurate ranges and was trying to reproduce this in VS and Rider but it seems they show it differently.

@auduchinok is Rider doing something to show a more accurate range ? . Because adding a test in the compiler with this exact snippet shows the ranges on the left(VS)

[auduchinok]

@auduchinok is Rider doing something to show a more accurate range ?

Yes, I've tried to workaround some cases on our side until a proper fix is landed into the compiler.