Unused binding warning isn't reported for recursive binding in a type

[auduchinok]

Consider the following type declaration:

type T() =
    let rec f x = ()
    and g x = ()

    do g ()

Earlier FCS versions would report f as unused with --warnon:1182 flag present, but the current main doesn't report it anymore.

@psfinaki Could it be somehow related to #13429?

[psfinaki]

@auduchinok not that I can think of a direct connection - but cannot say for sure since CheckExpressions.fs is a very interconnected thing and everything can happen there. Or maybe @dsyme you have insights on that?

Regardless, this is a regression, not good - @vzarytovskii FYI.

[vzarytovskii]

It is likely related to the way we check it (i.e. we don't emit warning if member/binding has CompilerGeneratedAttribute)
Here:

fsharp/src/Compiler/Checking/CheckIncrementalClasses.fs

Lines 291 to 293 in 638e479

	let reportIfUnused() =
	if not v.HasBeenReferenced && not v.IsCompiledAsTopLevel && not (v.DisplayName.StartsWithOrdinal("_")) && not v.IsCompilerGenerated then
	warning (Error(FSComp.SR.chkUnusedValue(v.DisplayName), v.Range))

And here:

fsharp/src/Compiler/Checking/PostInferenceChecks.fs

Lines 308 to 319 in 638e479

	if not env.external &&
	not alreadyDone &&
	cenv.reportErrors &&
	not v.HasBeenReferenced &&
	not v.IsCompiledAsTopLevel &&
	not (v.DisplayName.StartsWithOrdinal("_")) &&
	not v.IsCompilerGenerated then
	if v.IsCtorThisVal then
	warning (Error(FSComp.SR.chkUnusedThisVariable v.DisplayName, v.Range))
	else
	warning (Error(FSComp.SR.chkUnusedValue v.DisplayName, v.Range))

Right now, we emit the following IL (roughly):

.method assembly hidebysig instance void f<a> (!!a x) cil managed 
{
    .custom instance void [System.Runtime]System.Runtime.CompilerServices.CompilerGeneratedAttribute::.ctor() = (01 00 00 00)
    .maxstack 8
    IL_0000: ret
} // end of method T::f

.method assembly hidebysig instance void g<a> (!!a x) cil managed 
{
    .custom instance void [System.Runtime]System.Runtime.CompilerServices.CompilerGeneratedAttribute::.ctor() = (01 00 00 00
    .maxstack 8
    IL_0000: ret
} // end of method T::g

We've made some changes to codegen in the following PRs: #13542 and #13494

Update: it seems those only touch fields and properties, but not methods.
@0101 I know you looked into compiler-generated attribute, do you have any insights into this?

[dsyme]

Even just this is a repro:

type T() =
    let f _ = ()

[auduchinok]

@dsyme Ah, interesting, indeed. In all other tests we have a simple value, not a function, and the only function in these tests happened to be recursive. I should've tried to find a smaller repro (and perhaps we need more tests 🙂). Thanks for pointing it out!

[0101]

@vzarytovskii strange, the TypedTree.Val for f somehow gets the isCompGen flag. Not sure how.

[0101]

This seems to be where it happens.

[dsyme]

@0101 I think it is these lines:

                // NOTE: putting isCompilerGenerated=true here is strange.  The method is not public, nor is
                // it a "member" in the F# sense, but the F# spec says it is generated and it is reasonable to reflect on it.
                let memberValScheme = ValScheme(id, prelimTyschemeG, Some valReprInfo, None, Some memberInfo, false, ValInline.Never, NormalVal, None, true (* isCompilerGenerated *), true (* isIncrClass *), false, false)

[dsyme]

I added this comment here, though didn't change the setting at that point:

https://github.com/dotnet/fsharp/pull/12432/files#diff-1166ef31585c9572a1ef181219c1bf3ee6cb3a444d787f0179c06cda56e96439R979-R981

[dsyme]

Note that in the checking of incremental classes, two Val are in play in IncrementalClasses.fs:

• We initially create a non-member value f and do most checking with respect to that.
• After the class is fully checked we then later decide on the representation of each local let as either
  • a field
  • a constructor-local
  • a method
    If it's a method then we create a new member value f, mark it compiler-generated, and then substitute through the implementation code.

Most checking is done in TcCheck* and is done with respect to the "non-member" values which are not marked compiler-generated, however the "PostInferenceChecks" are done after the representations have been decided and so with respect to the "member" values. This is the underlying problem - the PostInferenceChecks are seeing too much of the internal compilation/representation process. We've talked about moving the IncrementalClasses representation-process into a later compiler phase - after PostInferenceChecks - but this is a larger bit of work.

I guess the fact that this is a representation-process is the reason we decided long ago to mark these as compiler-generated. Hwoever I don't know why any of this has changed recently - maybe we added the IsCompilerGenerated filter in PostInferenceChecks? @psfinaki did make a change to make the non-member vals visible to the the language service, but I don't think that should be affecting this.

Anyway, marking the "member values" as non-compiler-generated is probably OK in principle. However one problem is that there can be duplicates:

type C() =
    let f() = 1
    let f() = 2

This is allowed in F# - and the member-vals for the two f get different names, decided as the representations are chosen - in this case the member-val for the second member f is given name f@3. This is the TypedTree DisplayName/LogicalName of the member val for all post-checking - though we don't ever expect these to be reported in diagnostics.

This means a simple fix of "mark the value as non-compiler-generated" will lead to diagnostics like f@3 is unused in the second case above. It's not the end of the world if we show some compiler-generated name, but it's not "right" and it's odd that something with a compiler-generated logical name would not get marked IsCompilerGenerated - and maybe other problems will happen because of this

So maybe what we really want is two non-compiler-generated member-vals f both with the DisplayName f but with different LogicalName. There's currently no real way in the TypedTree for a Val to have a display name that is different to the logical name (except for op_..., properties etc.) but there's no real reason we can't add it. We would add it by a new optional field val_display_name_core_mangled here

fsharp/src/Compiler/TypedTree/TypedTree.fs

Line 2512 in 638e479

mutable val_compiled_name: string option

and using it here and here and here.

That might work out I think.