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

void fix for TPSDK running in .NET Core tooling #5621

Merged
merged 1 commit into from
Sep 12, 2018

Conversation

dsyme
Copy link
Contributor

@dsyme dsyme commented Sep 11, 2018

The F# compiler type provider API transacts System.Type/MethodInfo etc. object to describe the provided code.

The compiler (and compiler service) side of this has a few niggling warts which need really gnarly workarounds in the TPSDK . While we're still going to need to workaround these (in order for type providers to work with existing tooling), I'm going to try to push a few fixes into the compiler to make things slightly easier in the very long term.

This is the first such fix: the compiler hardwires a comparison with the compiler-runtime typeof<System.Void> as opposed to the target version of this type. This is wrong and leads to nasty workaround in the TPSDK here, which itself only works on some code paths, since not all code paths go through the comparison in the compiler. This is causing problems for type providers running in .NET Core tooling here:

error FS1108: The type 'Void' is required here and is unavailable. You must add a reference to assembly 'System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e'.  

(It didn't cause a problem for .NET Framework tooling because "Void" was always in "mscorlib" even at runtime.)

My belief is the easiest thing is to change the compiler to just use a string comparison on the System.Void type name here. I've made it additional just for safety. The TPSDK is doing this anyway, and is the only feasible means of authoring type providers, so there is no compat issue.

There's no point testing this in this repo as it would be hard to arrange and effectively need an import of the whole TPSDK into this repo.

@dsyme dsyme changed the title void fix for TPSDK void fix for TPSDK running in .NET Core tooling Sep 11, 2018
@@ -428,7 +428,7 @@ module internal ExtensionTyping =
member __.GetGenericArguments() = x.GetGenericArguments() |> ProvidedType.CreateArray ctxt
member __.ApplyStaticArguments(provider: ITypeProvider, fullTypePathAfterArguments, staticArgs: obj[]) =
provider.ApplyStaticArguments(x, fullTypePathAfterArguments, staticArgs) |> ProvidedType.Create ctxt
member __.IsVoid = (typeof<System.Void>.Equals(x))
member __.IsVoid = (typeof<System.Void>.Equals(x) || (x.Namespace = "System" && x.Name = "Void"))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Type.FullName returns "System.Void"

printfn "%s" (typeof<System.Void>.FullName);;
System.Void

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, though that's ever so slightly slower.... Also FullName is causing hell here: fsprojects/FSharp.TypeProviders.SDK#236 (comment) so preferring to rely on simpler primitives (under the hood the namespace and type name are stored separately)

@KevinRansom KevinRansom merged commit dbf345c into dotnet:master Sep 12, 2018
KevinRansom pushed a commit to KevinRansom/fsharp that referenced this pull request Sep 18, 2018
@cartermp cartermp added this to the 15.9 milestone Sep 19, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants