Bug: --standalone fails on generic method on generic interface on generic type #1689
Description
updated with preliminary investigation
Issue found when building #1570
Due to a generic method from a generic method on a generic class. The problem stems from ilread.fs line 2239 (I'll provide a link when I'm on something other than a mobile phone!). It calls readBlobHeapAsMethodSig passing 0 as the numtypes parameter. This value should, I think, be 2 to correspond to the following parameter count in the ISeqFactory floating types (in my case as listed below from which this issue was noticed). I had a little looks to see if I could understand how to traverse the data structures, buy they appear fairly non-trivial with lots of plain indexes being handed around.
Anyway, the code carries on for a bit before eventually crashing in pass3 of the binary writer when it tried to find the proper method, but due to this issue with ilread the matching signature cannot be found.
Running fsc with the arguments listed from ci_part2 below allow for relatively easy debugging to this point.
Anyway, back to the original text:
+++ Libraries\Portable (parse_tests.fs (Desktop)) +++
Compiling: [fsc --standalone -g -a parse_tests.fs ]
Microsoft (R) F# Compiler version 4.1
Copyright (c) Microsoft Corporation. All Rights Reserved.
The local method 'Microsoft.FSharp.Collections.SeqModule.Composer.SeqComponentFactory`2'::'Microsoft-FSharp-Collections-SeqModule-Composer-Internal-ISeqFactory`2-Create' was referenced but not declared
generic arity: 1
A method in 'Microsoft.FSharp.Collections.SeqModule.Composer.SeqComponentFactory`2' had the right name but the wrong signature:
generic arity: 1
mdkey2: Microsoft.FSharp.Compiler.AbstractIL.ILBinaryWriter+MethodDefKey
error FS2014: A problem occurred writing the binary 'C:\src\visualfsharp\tests\fsharpqa\Source\Libraries\Portable\parse_tests.dll': Error in pass3 for type Microsoft.FSharp.Collections.SeqModule, error: Error in pass3 for type Composer, error: Error in pass3 for type SeqComponentFactory`2, error: Error in GetMethodRefAsMethodDefIdx for mref = ("Microsoft-FSharp-Collections-SeqModule-Composer-Internal-ISeqFactory`2-Create",
"SeqComponentFactory`2"), error: Exception of type 'Microsoft.FSharp.Compiler.AbstractIL.ILBinaryWriter+MethodDefNotFound' was thrown.
Compile Unexpectedly Failed: 256
It causes failures in three places:
+++ Libraries\Portable (parse_tests.fs (Desktop)) +++
+++ Libraries\Portable (parse_tests.fs (Portable)) +++
+++ CompilerOptions\fsc\standalone (W_MissingTransitiveRef.fs) +++
This occurred after I had added the publicly accessible interface (which is I guess a bit unusual in that it is a generic interface that contains a generic method)
type ISeqFactory<'T,'U> =
abstract PipeIdx : PipeIdx
abstract Create<'V> : IOutOfBand -> ``PipeIdx?`` -> Consumer<'U,'V> -> Consumer<'T,'V>
Related types are:
type PipeIdx = int
type ``PipeIdx?`` = Nullable<PipeIdx>
type ICompletionChaining =
abstract OnComplete : PipeIdx -> unit
abstract OnDispose : unit -> unit
type IOutOfBand =
abstract StopFurtherProcessing : PipeIdx -> unit
[<AbstractClass>]
type Consumer<'T,'U> () =
abstract ProcessNext : input:'T -> bool
abstract OnComplete : PipeIdx -> unit
abstract OnDispose : unit -> unit
default __.OnComplete _ = ()
default __.OnDispose () = ()
interface ICompletionChaining with
member this.OnComplete terminatingIdx =
this.OnComplete terminatingIdx
member this.OnDispose () =
try this.OnDispose ()
finally ()
Repro steps
Build ci_part1 for #1570 (I haven't explorered if there are command line options to just run the single test?). There are other issues with that build, but I believe they are orthogonal.
Update: ci_part2 runs the command:
C:\src\visualfsharp\tests\fsharp\tools\bundle> C:\src\visualfsharp\release\net40\bin\fsc.exe -r:System.Core.dll --nowarn:20 --define:COMPILED --progress --standalone -o:test-one-fsharp-module.exe -g test-one-fsharp-module.fs
which also demonstrates this issue.
Expected behavior
For the compiler not to unexpectedly fail
Actual behavior
The compiler unexpectedly fails
Known workarounds
None
Related information
Occurs on local build as well as AppVeyor, so I assume it is consistent.