Fable 3 handles <TreatWarningsAsErrors> in referenced projects differently than Fable 2

[sasmithjr]

Description

Fable 3 handles <TreatWarningsAsErrors>true</TreatWarningsAsErrors> in referenced projects differently than Fable 2.

I have one project, Project A, that has turned on treating warnings as errors. Project B references A, and B contains some code with a warning. A's configuration causes B to treat the warning as an error when using Fable 3.

Repro code

Repo here

1. Clone repo
2. npm install
3. dotnet build ./tests to see that it builds with a warning
4. npm run test to see that Fable 2 runs the test with the warning
5. npm run test-nagareyama to see Fable 3 fails to build due to warning-as-an-error
6. Set <TreatWarningsAsErrors> to false (or comment the line out) in ./src/Stuff.fsproj
7. Re-run step 5 to see the test run and display the warning

Expected and actual results

Not sure what's expected. Saw the Fable3 blog posts say no expected breaking changes, so I thought I'd let y'all know just in case this is an issue.

Found while working to migrate to Fable 3.

Related information

• Fable version: fable-compiler v2.13.0 and fable 3.0.0-nagareyama-rc-008. Unsure if present in earlier RCs.

[alfonsogarciacaro]

Thanks for reporting @sasmithjr! Same as Fable 2, Nagareyama collects all sources and creates a single project with them for compilation. The difference in this case is that, while Fable 2 totally ignored compiler options from refererenced projects, Nagareyama takes some into account. We thought this would be more accurate but it's true in cases like yours this may have unexpected results. Maybe the warnings as errors option should only be set by the main project? What do you think @ncave?

[ncave]

@sasmithjr @alfonsogarciacaro This is correct, some options from referenced projects are collected, but the ones from the main project are applied last, so you have the opportunity to turn any of them off, e.g. in this case if you define <TreatWarningsAsErrors>false</TreatWarningsAsErrors> in your main project.

We opted to ignore certain options from referenced projects that don't make sense to be aggregated. Perhaps we can consider ignoring --warnaserror as well if you think that is breaking existing projects.

On a more philosophical note, yes, there can be theoretically many corner cases when options and symbols in referenced projects contradict each other, and it may be hard to get around that (except trying to work it out in the main project as mentioned above). Ignoring all these options is arguably just as bad, as some may be needed to properly compile those referenced projects. In theory, the only way to properly do this is to perhaps compile each referenced project in isolation (the same way dotnet does it), and then merge the generated javascript, but that's too big of a change for now.

[inosik]

Could we attach the options of the referenced projects to their files and pass them to FCS in the following line?

https://github.com/fable-compiler/Fable/blob/820ed876853b474f44c4ce67818e1c41141cfe95/src/Fable.Cli/Main.fs#L456

[sasmithjr]

the ones from the main project are applied last, so you have the opportunity to turn any of them off, e.g. in this case if you define <TreatWarningsAsErrors>false</TreatWarningsAsErrors> in your main project.

I updated my example repo by adding the explicit false flag for <TreatErrorsAsWarnings> here to the project which references the project with the warnings-as-errors flag, and it still errors out in the same way as previously when using Fable 3. Did I misunderstand what you meant by "main project"?

[alfonsogarciacaro]

Hmm, not sure how the MSBuild properties in .fsproj are translated to fsc cli args here, can you please try running fable with --verbose option @sasmithjr

@ncave @inosik Now that Fable AST doesn't contain direct references to entities which, in principle, should allow serialization, for Fable 3.1 I was thinking to precompile projects (which was not possible until now because of inlined expressions). I was thinking mainly in code from packages but maybe we could use this opportunity to move away from collecting sources and compile projects separately (as the standard F# compiler does) so we can apply different options per project as in this case.

[sasmithjr]

dotnet fable ./tests/ --outDir ./tests/nagareyama-output --verbose && mocha ./tests/nagareyama-output -r esm

Fable: F# to JS compiler 3.0.0-nagareyama-rc-008
Thanks to the contributor! @tomcl
tests> dotnet restore StuffTests.fsproj
  Determining projects to restore...
  All projects are up-to-date for restore.
Parsing tests/StuffTests.fsproj...
fable-library: ~/Code/fsharp/Fable/build/fable-library
F# PROJECT: tests/StuffTests.fsproj
   --define:NETSTANDARD
   --define:NETSTANDARD2_1
   --warnaserror
   --warnaserror:3239,76
   --define:NETSTANDARD
   --define:NETSTANDARD2_1
   --warnaserror:3239,76
   --noframework
   --nologo
   --simpleresolution
   --nocopyfsharpcore
   --define:FABLE_COMPILER
   --define:FABLE_COMPILER_3
   --optimize-
   --warn:3
   --fullpaths
   --flaterrors
   --target:library
   --langversion:preview
   --targetprofile:netstandard
   --optimize-
   -r:/usr/local/share/dotnet/packs/NETStandard.Library.Ref/2.1.0/ref/netstandard2.1/System.ValueTuple.dll
   -r:/usr/local/share/dotnet/packs/NETStandard.Library.Ref/2.1.0/ref/netstandard2.1/System.Threading.Tasks.dll
   -r:/usr/local/share/dotnet/packs/NETStandard.Library.Ref/2.1.0/ref/netstandard2.1/System.Threading.dll
   -r:/usr/local/share/dotnet/packs/NETStandard.Library.Ref/2.1.0/ref/netstandard2.1/System.Text.RegularExpressions.dll
   -r:/usr/local/share/dotnet/packs/NETStandard.Library.Ref/2.1.0/ref/netstandard2.1/System.Text.Encoding.Extensions.dll
   -r:/usr/local/share/dotnet/packs/NETStandard.Library.Ref/2.1.0/ref/netstandard2.1/System.Text.Encoding.dll
   -r:/usr/local/share/dotnet/packs/NETStandard.Library.Ref/2.1.0/ref/netstandard2.1/System.Runtime.Numerics.dll
   -r:/usr/local/share/dotnet/packs/NETStandard.Library.Ref/2.1.0/ref/netstandard2.1/System.Runtime.Extensions.dll
   -r:/usr/local/share/dotnet/packs/NETStandard.Library.Ref/2.1.0/ref/netstandard2.1/System.Runtime.dll
   -r:/usr/local/share/dotnet/packs/NETStandard.Library.Ref/2.1.0/ref/netstandard2.1/System.Reflection.Primitives.dll
   -r:/usr/local/share/dotnet/packs/NETStandard.Library.Ref/2.1.0/ref/netstandard2.1/System.Reflection.Extensions.dll
   -r:/usr/local/share/dotnet/packs/NETStandard.Library.Ref/2.1.0/ref/netstandard2.1/System.Reflection.dll
   -r:/usr/local/share/dotnet/packs/NETStandard.Library.Ref/2.1.0/ref/netstandard2.1/System.Numerics.dll
   -r:/usr/local/share/dotnet/packs/NETStandard.Library.Ref/2.1.0/ref/netstandard2.1/System.Net.Requests.dll
   -r:/usr/local/share/dotnet/packs/NETStandard.Library.Ref/2.1.0/ref/netstandard2.1/System.IO.dll
   -r:/usr/local/share/dotnet/packs/NETStandard.Library.Ref/2.1.0/ref/netstandard2.1/System.Globalization.dll
   -r:/usr/local/share/dotnet/packs/NETStandard.Library.Ref/2.1.0/ref/netstandard2.1/System.dll
   -r:/usr/local/share/dotnet/packs/NETStandard.Library.Ref/2.1.0/ref/netstandard2.1/System.Diagnostics.Tracing.dll
   -r:/usr/local/share/dotnet/packs/NETStandard.Library.Ref/2.1.0/ref/netstandard2.1/System.Diagnostics.Tools.dll
   -r:/usr/local/share/dotnet/packs/NETStandard.Library.Ref/2.1.0/ref/netstandard2.1/System.Diagnostics.Debug.dll
   -r:/usr/local/share/dotnet/packs/NETStandard.Library.Ref/2.1.0/ref/netstandard2.1/System.Core.dll
   -r:/usr/local/share/dotnet/packs/NETStandard.Library.Ref/2.1.0/ref/netstandard2.1/System.Console.dll
   -r:/usr/local/share/dotnet/packs/NETStandard.Library.Ref/2.1.0/ref/netstandard2.1/System.ComponentModel.TypeConverter.dll
   -r:/usr/local/share/dotnet/packs/NETStandard.Library.Ref/2.1.0/ref/netstandard2.1/System.ComponentModel.Primitives.dll
   -r:/usr/local/share/dotnet/packs/NETStandard.Library.Ref/2.1.0/ref/netstandard2.1/System.ComponentModel.dll
   -r:/usr/local/share/dotnet/packs/NETStandard.Library.Ref/2.1.0/ref/netstandard2.1/System.Collections.dll
   -r:/usr/local/share/dotnet/packs/NETStandard.Library.Ref/2.1.0/ref/netstandard2.1/System.Collections.Concurrent.dll
   -r:/usr/local/share/dotnet/packs/NETStandard.Library.Ref/2.1.0/ref/netstandard2.1/netstandard.dll
   -r:/usr/local/share/dotnet/packs/NETStandard.Library.Ref/2.1.0/ref/netstandard2.1/mscorlib.dll
   -r:~/.nuget/packages/fsharp.core/4.7.0/lib/netstandard2.0/FSharp.Core.dll
   -r:~/.nuget/packages/fable.core/3.1.5/lib/netstandard2.0/Fable.Core.dll
   ~/Code/adaptive-fable3/src/Main.fs
   ~/Code/adaptive-fable3/tests/Util.fs
   ~/Code/adaptive-fable3/tests/Main.fs
Initializing F# compiler...
Compiling tests/StuffTests.fsproj...
F# compilation finished in 2513ms
~/Code/adaptive-fable3/tests/Main.fs(8,21): (8,25) error FSHARP: The recursive object reference 'this' is unused. The presence of a recursive object reference adds runtime initialization checks to members in this and derived types. Consider removing this recursive object reference. (code 1183)
Compilation failed

This is the output. I replaced my home directory with ~; otherwise, it's unchanged.

Looking at it, it seems <TreatWarningsAsErrors>false</TreatWarningsAsErrors> does not translate to an explicit --warnaserror- (which I believe would be the explicit way to turn it off from here). Having <TreatWarningsAsErrors> as false means no cli arg, so that would be why the reference project's settings are being used in this case.

[alfonsogarciacaro]

Thanks @sasmithjr. Ok, for now I've disabled --warnaserror in project references. We can try later to compile each project (with each own options) separately.

[piaste]

It's not nearly as critical as the opposite problem which @sasmithjr is having, but I used to lean a fair bit on TreatWarningsAsErrors and this patch has disabled it, which is a little annoying.

Can anyone suggest a good workaround? I tried adding an extra watch command, going from:

dotnet fable watch src --runWatch parcel index.html

to:

dotnet fable watch src --runWatch dotnet build src && parcel index.html

but that ran afoul of this issue with Fable 3.2 so it would fail every time 😓

[ncave]

@piaste I believe --warnaserror is ignored only in referenced projects, does it work if you enable it in the main project instead?