fsprojects / FSharp.TypeProviders.SDK

The SDK for creating F# type providers
https://fsprojects.github.io/FSharp.TypeProviders.SDK/
MIT License
298 stars 94 forks source link

Cannot generate usable interfaces #211

Closed panesofglass closed 2 years ago

panesofglass commented 6 years ago

Description

I ran into the following problems while trying to generate interfaces in the generative SwaggerProvider:

Repro steps

Please provide the steps required to reproduce the problem

  1. Clone https://github.com/panesofglass/SwaggerProvider and switch to the api-interfaces branch.

  2. Run git reset --hard bb2a984101f767b689e49ed63ee38bfd607ffe89 to get to the interfaces implementation.

  3. Run build.cmd to run the FAKE build.

  4. Observe that, just after starting RunUnitTests, the program breaks with the following error:

    screen shot 2018-03-14 at 4 01 24 pm
  5. Comment out generation of the interfaces to observe that the type provider runs tests successfully: https://github.com/panesofglass/SwaggerProvider/blob/api-interfaces/src/SwaggerProvider.DesignTime/SwaggerProviderConfig.fs#L89

  6. To see the ProvidedMethod issue, roll back to this commit and run the build, then inspect the generated SwaggerProvider.ProvidedTests assembly for the Swagger.PetStore.Tests.PetStore.Contract type.

Expected behavior

  1. ProvidedTypeDefinition with TypeAttributes.Public ||| TypeAttributes.Interface ||| TypeAttributes.Abstract attributes should generate an interface that can be loaded at runtime.

  2. Generated interfaces should be able to contain generated methods.

  3. Generated interfaces should be implementable by user types.

  4. Generated interfaces should be implementable on generated types within the type provider.

Actual behavior

  1. Runtime fails to load the generated interface type, causing, in this case a test assembly, to crash even when the generated interface is not used.

  2. Generated interface methods are not public abstract method but public extern method.

Known workarounds

None.

Additional information

panesofglass commented 6 years ago

This situation also appears to be true when trying to generate an abstract class with abstract methods, though it seems to only be the methods in this case. See https://github.com/panesofglass/SwaggerProvider/pull/2/commits/983b1a3dc0471cffe0c64fba6ab9b4ffab0fc091

panesofglass commented 6 years ago

I found a potential work-around using an abstract class with virtual methods, but the generated methods once again appear incorrect:

screen shot 2018-03-14 at 4 51 51 pm

Based on other abstract classes such as System.IO.TextReader, that should be a public virtual method:

screen shot 2018-03-14 at 4 56 15 pm

See https://github.com/panesofglass/SwaggerProvider/pull/2/commits/d88ba1cd256e7c8e593b2f2bde450cf83ac2958f

panesofglass commented 6 years ago

I am happy to help sort these into different bugs and work on smaller repros, if that's useful, but I'll need some help, at least for the first one.

panesofglass commented 6 years ago

I think I can add tests to show these are not working properly. I’ll try to get them properly failing and submit a PR, if that is useful.

thinkbeforecoding commented 2 years ago

I think this has been fixed by #311 We may close this

cartermp commented 2 years ago

Thanks, will close.