Fix #2521: Enable TreatWarningsAsErrors (breaking?)

[alfonsogarciacaro]

See #2521 (comment)

[inosik]

Is it possible to attach the project where a file came from, when we collect all the files? And can we pass this information to the compiler here:

https://github.com/fable-compiler/Fable/blob/main/src/Fable.Cli/Main.fs#L507

Then we could compile each file with the options from the respective project, I imagine.

[alfonsogarciacaro]

Not sure if that will work. That "compiler" is the fable compiler which indeed compiles file one by one, but most errors come from the F# compiler and this compiles all files at once so we cannot use different options:

Fable/src/Fable.Cli/Main.fs

Line 351 in 4d9172e

checker.ParseAndCheckProject(config.ProjectOptions.ProjectFileName, filePaths, sourceReader)

[alfonsogarciacaro]

Another thing we could try and I've been considering for a while is first compiling the sources of the packages and later the user sources referencing the .dlls. This would allow us to use different F# compilation options for the packages (--warnaserror in this case) and it should be also beneficial in terms of memory, because we don't need to keep the full memory of the typed F# AST for the package sources, online the parts corresponding to inlined functions.

My actual hope was to be able to serialize the inlined functions from the packages so you could even just cache the result and skip F# compilation for them. But this is proving to be difficult so maybe just a 2-step compilation is enough.

I remember also @dbrattli needs to compile packages in a different way for Python, so this could also help him.

[inosik]

That "compiler" is the fable compiler which indeed compiles file one by one, but most errors come from the F# compiler

Got it. I guess I should get familiar with how the all of this is set up 😅

Re: inline functions, the F# compiler should have something for that, right? It's able to inline functions from other assemblies, so it must store some representation of these functions in the assembly. And read it back again when compiling code that uses such a function.

[alfonsogarciacaro]

TBH, I'm not entirely sure, but I assume the F# compiler inlines directly the IL code from the .dll assemblies. To my knowledge there's no way to get the typed AST that Fable needs for compilation from a .dll, only from source files. Actually inlining is not done in the typed AST, that's why Fable needs to do it by itself.

If you pass the --optimize option to the F# compiler, it does inline in the typed AST. But then you get lots of IL bits in the typed AST which causes trouble with Fable.

Funny enough, Funscript did work with .dll assemblies. But it used quotations not the typed AST, and users had to decorate all modules with ReflectedDefinition.

[alfonsogarciacaro]

Actually, the last comment gave me an idea, but it's a long shot. We could ask library authors to use ReflectedDefinition in their packages and then Fable can get the quotations without the sources. But for that we would need to add a Quotation2Fable step.