Build fails without prior feed-back when reusing names for DU constructors and IWSAM members

[Savelenko]

Consider the following program:

type SensorReadings = int

type EngineError<'e> =
    static abstract Overheated : 'e
    static abstract LowOil : 'e

let startEngine<'e when EngineError<'e>> (sensorReading : SensorReadings) : Result<unit, 'e> =
    if sensorReading <= 10 then Error 'e.Overheated
    elif sensorReading <= 20 then Error 'e.LowOil
    else Ok ()

type AudioError<'e> =
    static abstract DeviceNotPaired : 'e

let initializeAudio<'e when AudioError<'e>> (sensorReading : SensorReadings) : Result<unit, 'e> =
    if sensorReading <= 30 then Error 'e.DeviceNotPaired else Ok ()

type CarError2 =
    | Overheated2
    | LowOil2
    | DeviceNotPaired2

    interface EngineError<CarError2> with
        static member Overheated = Overheated2
        static member LowOil = LowOil2
    // There seems to be a compiler bug here. An interesting error is produced very late during
    // building if "2" is removed from DU constructor names. I expect it to be possible to
    // reuse the names, as normally possible in F#.

    interface AudioError<CarError2> with
        static member DeviceNotPaired = DeviceNotPaired2

let startCar (sensorReading : SensorReadings) : Result<unit, CarError2> = result {
    // Prioritize engine errors above audio errors
    do! startEngine sensorReading
    do! initializeAudio sensorReading
}

Note the "2" in the naming of DU constructors and the note above. When leaving the "2"s out, Visual Studio does not provide any feed-back (warning, etc.) so everything seems OK. However, building produces the following seemingly very low-level error:

Build started...
1>------ Build started: Project: IWSAMDemo, Configuration: Debug Any CPU ------
1>FSC : error FS2014: A problem occurred writing the binary 'obj\Debug\net7.0\refint\IWSAMDemo.dll': Error in pass2 for type ErrorMerging, error: Error in pass2 for type CarError2, error: duplicate entry 'Overheated' in property table
1>Done building project "IWSAMDemo.fsproj" -- FAILED.
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
========== Elapsed 00:01,464 ==========

[vzarytovskii]

Oh, that's an interesting one @dsyme.
Phase2 confuses the DU constructor and property from interface in the properties table.

[vzarytovskii]

Minimal repro:

type Interface =
    static abstract Case: Implementation

and Implementation =
    | Case
    interface Interface with
        static member Case = Case

When static member name is the same as DU case name and the type of the field is DU, it fails to create the second one.

It was the case even before IWSAMs, but we have a better error for it:

type Implementation =
    | Case
    static member Case = Case

will produce

> type Implementation =
-     | Case
-     static member Case = Case;;

      static member Case = Case;;
  ------------------^^^^

stdin(100,19): error FS0023: The member 'Case' can not be defined because the name 'Case' clashes with the union case 'Case' in this type or module

Not much we can do to allow it, just make the error better.

Update: or alternatively, we could store explicit interface properties (static Implementation Interface.Case => Case;) differently (i.e. using their full name), since it might be a valid use case (however, names+types clash would be rather rare, I guess).

[dsyme]

I'm a little surprised we're not emitting an explicit method impl for these cases. I don't see any intrinsic reason why it shouldn't be compilable if we did?

That is, for the interface implementations

[vzarytovskii]

I'm a little surprised we're not emitting an explicit method impl for these cases.

We do, for

type Interface =
    static abstract Case: Implementation

and Implementation() =
    interface Interface with
        static member Case = Implementation()

We will emit something like:

public class Implementation : Interface
{
	static Implementation Interface.Case => new Implementation();
}

I don't see any intrinsic reason why it shouldn't be compilable if we did?

Yeah, I think it's the name we use in ilwrite when store properties.

[edgarfgp]

@vzarytovskii Im trying to understand if this fixable. If so, I would love some guidance if you have sometime.