Some values marked as unused do not become warnings when using --warnon:1182

[TysonMN]

There are some cases in which values are correctly distinguished in Visual Studio as being unused but they do not become warnings when using --warnon:1182.

Reproduction Steps

Consider the following code (zip of solution) in which x, y, and z are all unused.

module Top
type Foo =
  { Bar: Unit }
  member x.Baz() = ()
let private y = ()
let f z = ()

Visual Studio correctly displays them as unused via the darker font color and tool tips mention FS1182.

x tooltip

val x : Foo
FS1182: The value is unused

y tooltip

val private y : unit
Full name: Top.y
FS1182: The value is unused

z tooltip

val z : 'a
FS1182: The value is unused

Now to the project file, add

<OtherFlags>$(OtherFlags) --warnon:1182</OtherFlags>

Expected Behavior

I expected there to be three warnings...one for each unused value.

Actual Behavior

There is only one warning (screenshot), and it is for z. The tooltip for z also changes slightly.

new z tooltip

val z : 'a
FS1182: The value is unused
FS1182: The value 'z' is unused

Known workarounds

None

Related information

• Operating system: Windows 10
• .NET Runtime kind: .NET Core 3.1
• Editing Tools: Visual Studio Enterprise 2019 version 16.7.1

[abelbraaksma]

The warnings in the editor use a different method than the one from the compiler. The editor actually shows more unused items (like a private member), that the compiler won't.

In other cases, when both the editor and compiler agree, you can see two warnings in the warnings window, but one warning when you compile.

I'm actively working on this as part of wider issues with warnings related to compiler directives: #9906

Btw, it's not my intention to add flow analysis, that's a feature of the editor (f# compiler services), unless I find an easy way to bring the two in line. But it is my intention to get rid of the confusing, or duplicate tooltips, and some other issues mentioned in this and other reports.

[cartermp]

Yeah, this is kind of tricky. Historically the compiler switch was only ever designed for local let-bound values. The unused value analysis came afterwards and is more complete. I suppose the two could be unified somehow, but they're done in very different ways and it could also be that the compiler switch doesn't operate on enough data to make the kind of decisions that the analyzer does.

[dsyme]

I'm going to close this as the compiler switch is working as expected

[TysonMN]

I didn't mean to suggest that there is something wrong with the complier switch.

Should I open separate issues for x and y as not being reported as warnings? How should I describe the problems so that the issues don't get closed because "working as expected"?