6.0.400 compilation error with private types in namespace used in a different file

Repro steps

Defining a private type in a namespace and using it in a module in another file in the same namespace leads to a compilation error in 6.0.400.

Compiles without error in 6.0.300.

A simple repro can be found here: https://github.com/l3m/fsharp-error-repro

Expected behavior

Unclear if the behavior in 6.0.300 or 6.0.400 is the actually correct one, but it’s certainly a change.

So the expectation would have been that it compiles in 6.0.400

Actual behavior

Fails to compile in 6.0.400

Known workarounds

Replace

type private Blah = ... 

with

type internal Blah = ... 

Related information

Observed on both linux and windows, with dotnet sdk 6.0.300 and 6.0.400

[dsyme]

By using this diff https://github.com/dotnet/fsharp/compare/main...dsyme:cwe?expand=1 it looks like these are the origin points for structural equality

let isPublicVal (lv: Val) = (lv.Accessibility = taccessPublic)
let isPublicUnionCase (ucr: UnionCaseRef) = (ucr.UnionCase.Accessibility = taccessPublic)
let isPublicRecdField (rfr: RecdFieldRef) = (rfr.RecdField.Accessibility = taccessPublic)
let isPublicTycon (tcref: Tycon) = (tcref.Accessibility = taccessPublic)

Also this in AccessibilityLogic:

        | AccessibleFrom(cs1, tc1), AccessibleFrom(cs2, tc2) -> (cs1 = cs2) && (match tc1, tc2 with None, None -> true | Some tc1, Some tc2 -> tyconRefEq g tc1 tc2 | _ -> false)

One option is to switch to NoEquality and NoComparison on Accessibility and CompilationPath and use an explicit equality routine in the above places.

Another is to use the custom equality like @nojaf above, though I think perhaps just making everything more explicit is better. There are enough notions of equality needed in the compiler its better to be explicit for anything in TypedTree

[vzarytovskii]

Ok, thanks for the quick response. We’ll have to hold out another month or two then. 😢

Yeah, sorry for that, was a bit unfortunate timing on our side.