Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

error FS0192: internal error: Error in pass3 for some F# code. #18066

Closed
sylvainouel opened this issue Nov 27, 2024 · 6 comments · Fixed by #18081
Closed

error FS0192: internal error: Error in pass3 for some F# code. #18066

sylvainouel opened this issue Nov 27, 2024 · 6 comments · Fixed by #18081

Comments

@sylvainouel
Copy link

Repro steps

Copy/paste the following program in F# interactive:

type A = {
    F: uint64  
}

type B = {
    C: uint64[]
}

let g x =
    let c = 
        [|
            for d in x.C do
                {
                    F = d
                }
        |]
    c

It produces the following error:

error FS0192: internal error: Error in pass3 for type FSI_0003, error: ldelem

Expected behavior

I think it should build fine.

Actual behavior

internal error

Known workarounds
changing the uint64 to int64 fixes it.

Related information

It used to work, it stopped working after upgrading to latest VS.

  • Operating system
    Windows 11

  • .NET Runtime kind (.NET Core, .NET Framework, Mono)

.NET 9

  • Editing Tools (e.g. Visual Studio Version, Visual Studio)
    Microsoft Visual Studio Enterprise 2022 (64-bit) - Current
    Version 17.12.1
@brianrourkeboll
Copy link
Contributor

This seems like it could be related to some of my changes. I will try to take a look tomorrow.

@T-Gro
Copy link
Member

T-Gro commented Nov 27, 2024

This a regression from NET8, I also suspect the lowering changes being applied here.
Even though the previous version was already optimized to Array.map, so it could be a different cause of the regression.

https://sharplab.io/#v2:DYLgZgzgPg9gDgUwHYAIDKBPCAXBBbAWACgBtAHgDkYBRARwFcBDYAS2wwG4qBhGPORgCcWEGEgB8AXWLtEKAIIoAvCgDexFJpQAxECnosk2AGwAWTcQC+xclTpNW7LjF78hIsVJkY5AIWVqGlrcegZGZiTSRNZExMAI2CgA5igAHspBmvGJAMYBmVqaJFAFhYVgMIIoACYohmkAdNw1MKVl7epE7d3d2gHVbT2aMT1QUYU5QA==

@brianrourkeboll
Copy link
Contributor

Here's a more minimal repro:

[|for x in [|1UL|] -> x|]

The same thing applies for unativeint:

[|for x in [|1un|] -> x|]

The problem seems likely to be here

let ldelem = mkIlInstr g I_ldelem (fun ilTy -> I_ldelem_any (ILArrayShape.SingleDimensional, ilTy)) srcIlTy
let stelem = mkIlInstr g I_stelem (fun ilTy -> I_stelem_any (ILArrayShape.SingleDimensional, ilTy)) destIlTy

and here

let private mkIlInstr (g: TcGlobals) specific any ilTy =
if ilTy = g.ilg.typ_Int32 then specific DT_I4
elif ilTy = g.ilg.typ_Int64 then specific DT_I8
elif ilTy = g.ilg.typ_UInt64 then specific DT_U8
elif ilTy = g.ilg.typ_UInt32 then specific DT_U4
elif ilTy = g.ilg.typ_IntPtr then specific DT_I
elif ilTy = g.ilg.typ_UIntPtr then specific DT_U
elif ilTy = g.ilg.typ_Int16 then specific DT_I2
elif ilTy = g.ilg.typ_UInt16 then specific DT_U2
elif ilTy = g.ilg.typ_SByte then specific DT_I1
elif ilTy = g.ilg.typ_Byte then specific DT_U1
elif ilTy = g.ilg.typ_Char then specific DT_U2
elif ilTy = g.ilg.typ_Double then specific DT_R8
elif ilTy = g.ilg.typ_Single then specific DT_R4
else any ilTy

I think we need to be emitting ldelem.i8 and ldelem.i for uint64 and unativeint, respectively. (And maybe likewise for stelem?)

Even though the previous version was already optimized to Array.map

That was an intermediate optimization introduced in #16948, but superseded in #17067 in part to fix debug stepping in the loop body. SharpLab still has a preview version of 9 that doesn't include #17067, #17419, #17711.

@brianrourkeboll
Copy link
Contributor

Known workarounds
changing the uint64 to int64 fixes it.

@sylvainouel Another workaround for the time being would be to set <LangVersion>8.0</LangVersion> in your project file.

@brianrourkeboll
Copy link
Contributor

I opened a PR that I believe should fix this: #18081.

@sylvainouel
Copy link
Author

Thank you for this fix!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

3 participants