-
Notifications
You must be signed in to change notification settings - Fork 94
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
StackOverflow with TryBindType - GetType loop #182
Comments
This is mostly valid for .NET Standard libraries using type-providers: |
Adding just if nm.StartsWith("System.") then
Type.GetType nm
else to the override x.GetType (nm:string) of ProvidedTypes.fs will get rid of stackoverflow, but the .NET Standard build still fails:
|
System.Numerics.BigInteger problem is a bit different: fsc.exe compiler tries to evaluate auto-opens of the reference assemblies and FSharp.Core.dll has some references like Microsoft.FSharp.Core.bigint |
@Thorium The library is |
@Thorium Am I correct that you are seeing this bug when using a type provider to generate code for .NET Standard 2.0? We need to add testing for that scenario, thanks |
Correct. |
@Thorium That's not quite what's need to test targeting .NET Standard 2.0 in code generation. I'll work on testing this today, will send a link |
With the latest changes, targeting to .NET Standard, ProvidedTypes.fs dllInfos is null here: [ for dllInfo in dllInfos.GetElements() -> (dllInfo.GetProperty("FileName") :?> string)
if not (isNull baseObj) then
for dllInfo in baseObj.GetProperty("Value").GetField("dllInfos").GetElements() -> (dllInfo.GetProperty("FileName") :?> string) ] Now, this can be skipped with adding a corresponding isNull for dllInfos. But if we skip these dlls the compiler will be in the loop of stack-overflow described in this bug. By adding a check in #183 the stackoverflow is avoided. |
Maybe the problem is that the tcImports is not working correctly on .NET Standard target and trying to fix the side-effects won't help. |
@Thorium I see. |
Getting the latest #194 and trying to build the library using the type provider, compiling with .NET Standard 2.0 still gives: C:\Program Files\dotnet\sdk\2.1.2\FSharp\Microsoft.FSharp.Targets(263,9): error MSB6006: "fsc.exe" exited with code -1073741571. And with more diagnostics:
I have the definition in the fsproj file: <PropertyGroup Condition="'$(IsWindows)' == 'true'">
<FscToolPath>C:\Program Files (x86)\Microsoft SDKs\F#\4.1\Framework\v4.0</FscToolPath>
<FscToolExe>fsc.exe</FscToolExe>
</PropertyGroup> fsc.exe file version is 2017.11.4.1, product version 4.4.1.0 I expect that again this is the loop mentioned in the title of this bug. |
Why is ProvidedTypes.fs line |
When you say "compiling with .NET Standard 2.0" what do you mean? Compiling SqlProvider? Or one of the samples? Or putting |
That is correct for TargetTypeDefinition. The SDK builds a reflection model of types in the target assemblies. Also other assemblies will be interrogated for these types, returning null if they are not present. |
I mean I'm compiling a project that is using a type provider. In my case any of SQLProvider samples at https://github.com/fsprojects/SQLProvider/tree/master/tests/SqlProvider.Core.Tests in a slight modification that their target is netstandard2.0: The type provider, SQLProvider, itself compiles nicely. But users of that cannot target to nestandard2.0 So I expected that adding netsrandard2.0 target to FSharp.TypeProviders.SDK.Tests.fsproj would also replicate the same problem, if that project is returning anything from any reference-dll like FSharp.Core. The only modification needed is that .NET Standard is a library, not executable, so there shouldn't be EntryPointAttribute in NET Standard compilation. |
@Thorium Ah I see, thanks. FSharp.TypeProjects.SDK.Tests.fsproj is not actually using a type provider (i.e. as a compiler addin), but rather directly unit-testing the type provider SDK at the level of provided types and their properties. But perhaps now I can repro the problem by compiling SqlProvider. |
Those tests do use NuGet reference of SQLProvider (as referencing direct files was broken when I started with .NET Core). I just pushed the latest updated ProvidedTypes.fs version as SQLProvider 1.1.26-alpha1 to NuGet. |
@Thorium I tried to use the following repro steps and still couldn't repro it:
All commands succeeded, when I look at the generated DLL it has generated .NET Standard 2.0 code successfully. This is with the latest TPSDK (which the project uses by default). What am I missing? Thanks! Here's the code adjustment to use the default database:
|
Hi, Now my question is (documentation related, and maybe stupid, but keep in mind I don't know the details of .NET Core compilation well, I'm just a user): |
@Thorium Great, thanks for letting me know!
Looking at the way your type provider works, you will indeed need For now I think the nuget package should look like this:
Eventually you will need to also make some changes to use the type provider in conjunction with the F# compiler that comes in the .NET SDK (which runs on .NET Core, as opposed to the one you get via setting FscToolPath here). For now don't worry about it though - the F# compiler in the .NET SDK has not yet been updated and there are still ongoing discussions about how exactly a type provider will be packaged to work with both the
In your cases it has external references. In TP jargon you have your TPRTC and TPDTC in one combined DLL. |
(@Thorium note I updated the comment above, my first version was inaccurate) BTW I believe that in the long run you won't need the .NET 4.5.1 version of the type provider at all. The only place I can see where the netstandard2.0 and net451 TPDTCs vary is here:
But I suspect this can just be deleted - and that For now the .NET 4.5.1 TPDTC is still needed for backwards compat, since .NET Standard 2.0 is not supported pre .NET 4.7 |
ProvidedTypesContext class has a function of tryGetTypeFromAssembly
That calls
asm.GetType fullName |> function null -> None | x -> Some (x, true)
which calls TargetAssembly's method:
which calls TryBindType which contains call back to GetType and the loop is ready
GetType "System.Object"
-> TryBindType Some("System") "Object"
-> GetType "System.Object"
-> TryBindType Some("System") "Object"
-> ...
The text was updated successfully, but these errors were encountered: