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

Added ParseAndCheckFileInProject #1714

Merged
merged 1 commit into from
Jan 28, 2019

Conversation

ncave
Copy link
Collaborator

@ncave ncave commented Jan 28, 2019

@alfonsogarciacaro @MangelMaxime This enables implementing a multi-file tree view pane in the REPL.

@MangelMaxime
Copy link
Member

@ncave Awesome 🎉

And ok message received I will see what I can do about that :)

@alfonsogarciacaro
Copy link
Member

Fantastic! 👏 👏 Thank!

@alfonsogarciacaro alfonsogarciacaro merged commit 4de2e9b into fable-compiler:master Jan 28, 2019
@ncave
Copy link
Collaborator Author

ncave commented Jan 28, 2019

Just to clarify, there are 3 parse and check methods now:

  • ParseFSharpScript: checker * fileName: string * source: string
    This is the original, single file only, left as is for backwards compatibility.
    Despite the name, there is no support for #load etc.

  • ParseFSharpProject: checker * projectFileName: string * fileNames: string[] * sources: string[]
    Parses and checks the whole project, good for compilers (Fable etc.) but does not retain name resolutions and symbol uses which are quite memory hungry (so no intellisense etc.). Already parsed files will be cached so subsequent compilations will be faster.

  • ParseFSharpFileInProject: checker * fileName: string * projectFileName: string * fileNames: string[] * sources: string[]
    Parses and checks file in project, will compile and cache all the files up to this one if not already done before, or fetch them from cache. Returns partial project results, i.e. only up to and including the file requested. Returns name resolutions and symbol uses for the file (only), so intellisense etc. works.

@alfonsogarciacaro
Copy link
Member

alfonsogarciacaro commented Jan 29, 2019

Thanks @ncave! Can we add this information as doc comments in the actual methods and if possible also add some information in the method name itself (e.g. ParseFSharpProjectWithoutSymbolUses)?

@alfonsogarciacaro
Copy link
Member

alfonsogarciacaro commented Jan 29, 2019

Another question: the InteractiveChecker must be recreated whenever the dll references change. Because the Fable CLI can compile several projects at once it means we need to recreate a checker every time we parse a project file in case the references change. Are these references also cached? I mean, if I load two projects and they contain the same references will they be reused (or if I discard the checker and recreate it again because the .fsproj file has changed).

If this doesn't work I guess we need to create our own cache in the readAllBytes function, but this will still force the checker to parse the assemblies multiple times (I'm not sure how costly that operation is).

@ncave
Copy link
Collaborator Author

ncave commented Jan 29, 2019

@alfonsogarciacaro Raising the REPL bar from multi-file to multi-project, I see :) I like it!

Currently the InteractiveChecker contains the loaded references and the parse and typecheck caches, so if you discard it it's gone. It's not really meant to be reused for different projects, although that might be possible if there is no change in references. We may have to modify the caching to account for that, if that is really a desirable functionality (i.e. add project name to typecheck cache keys).

Technically you can reuse the InteractiveChecker without any change if you clear cache between projects.

About reusing references between multiple projects, do you mind describing the use case for it?
The fable-compiler-js is merging all project references into one big project, so that's probably not it.
Fable on dotnet should be using FCS as is (even when project-referenced from a ms/visualfsharp fork).

@alfonsogarciacaro
Copy link
Member

Actually I'm playing with the idea we discussed before about using your fork directly instead of the FCS package even in the Fable CLI (dotnet). Because the CLI acts as a server and because Webpack can have multiple project entries (or you can even import another .fsproj from F# using Webpack as the REPL itself does) we've to support compilation of multiple projects.

Another issue I'm also having is the InteractiveChecker expects references to be only file names (without the .dll extension) instead of full paths. But this is tricky if the .dlls come from Msbuild resolution and are located in different folders (like different packages in the Nuget cache. I'm getting an error here. Is it possible for you to get the File Name (without the parent directory) of the reference after passing the full path?

Anyways, if you think this doesn't make sense, we can go back and make Fable.Cli depend on the FCS package. I was just trying to uniform the different components and if you finally redirect your fork to visualfsharp it could be a way to get enhancements faster. But these are not showstoppers :)

@ncave
Copy link
Collaborator Author

ncave commented Jan 29, 2019

@alfonsogarciacaro You can still use my fork, or any other fork, or no fork (directly), if you are project-referencing FCS (by source from Microsoft/Visualfsharp, so you get latest). IMO Fable on dotnet should be project-referencing stock FCS, which is the officially supported tooling, used by everybody else, and guaranteed to work. Since Fable on dotnet is using dotnet anyway, and dotnet build resolutions, there is no reason not to. I don't see any benefit in trying to unify the last step (the CLI), as it inevitably will degrade quality and reliability.

fable-compiler-js (and REPL by extension), on the other hand, is in a different boat, as its whole point is to only use javascript. Hense we have to do regex-parsing for project files, dependencies, etc. It's very doable to add integration with fable-splitter to have common tooling afterwards, but that's pretty much the extend of it, as we don't want to re-implement MSBuild in javascript.

@ncave
Copy link
Collaborator Author

ncave commented Jan 29, 2019

Another issue I'm also having is the InteractiveChecker expects references to be only file names (without the .dll extension) instead of full paths.

The "without the .dll" part is a historic artifact, back from the olden days a few years back when FSharp.Core.dll was still distributed with a signature file on the outside. This can be changed.
Yes, we should be stripping the path from the assembly name after reading the bytes but before importing, that should fix it.

@alfonsogarciacaro
Copy link
Member

I was hoping we could take advantage of the improvements you added, like skipping the symbol uses to reduce the memory pressure, using hashes to cache the file contents, etc. With the "standard" FCS there are several things I don't understand well and I'm not sure if I'm doing things correctly. For example, for the first compilation I use checker.ParseAndCheckProject but for the watch compilations I use checker.ParseAndCheckFileInProject, but the first time I call this function is much slower than the others. Also, I need to keep a dependency map for each file myself to know which other files I need to recompile when one has changed.

In any case, for now I just added a workaround for the issue with the dll paths and it's working! 🎉 I will test it tomorrow with some of my projects to see if watch compilation times improve.

@ncave
Copy link
Collaborator Author

ncave commented Jan 30, 2019

Some of those improvement may be already there in recent changes in MS F# (like using source hashes in cache keys), so they will eventually trickle down to FCS.

@alfonsogarciacaro
Copy link
Member

Hmm, I'm getting issues with the fileNames on Windows :/ So I guess we'll have to stick with "official" FCS as you said :) I'll try to compile it directly from the visualfsharp repo to see if we can support anonymous records.

@ncave
Copy link
Collaborator Author

ncave commented Jan 30, 2019

@alfonsogarciacaro What kind of issues? The paths in file names need to be normalized?
This is probably unrelated, but the assumption is that all names are unique, so for example in fable-compiler-js the file names are prepended with the project folder.

@alfonsogarciacaro
Copy link
Member

For example, when building the library on Windows, at this point I'm passing the following file names:

C:/Users/alfon/dev/fable/src/fable-library/Global.fs
C:/Users/alfon/dev/fable/src/fable-library/BigInt/n.fs
C:/Users/alfon/dev/fable/src/fable-library/BigInt/z.fs
C:/Users/alfon/dev/fable/src/fable-library/BigInt.fs
C:/Users/alfon/dev/fable/src/fable-library/System.Text.fs
C:/Users/alfon/dev/fable/src/fable-library/FSharp.Collections.fs
C:/Users/alfon/dev/fable/src/fable-library/FSharp.Core.fs
C:/Users/alfon/dev/fable/src/fable-library/Array.fs
C:/Users/alfon/dev/fable/src/fable-library/List.fs
C:/Users/alfon/dev/fable/src/fable-library/Set.fs
C:/Users/alfon/dev/fable/src/fable-library/Map.fs

But the implementation files returned are only:

C:/Users/alfon/dev/fable/src/fable-library/BigInt.fs
C:/Users/alfon/dev/fable/src/fable-library/Array.fs
C:/Users/alfon/dev/fable/src/fable-library/List.fs
C:/Users/alfon/dev/fable/src/fable-library/Set.fs
C:/Users/alfon/dev/fable/src/fable-library/Map.fs

Those in a subfolder or with a dot in the name are missing. It was working on macOS yesterday so I assume it has to do with the normalization of the path separators,

@ncave
Copy link
Collaborator Author

ncave commented Jan 30, 2019

That may not be it the whole story, why is then Global.fs not there.

@alfonsogarciacaro
Copy link
Member

alfonsogarciacaro commented Jan 30, 2019

@ncave Some more findings/questions:

  • The problem with the file paths on Windows seemed to be the drive letter (like C:). After removing it now it's working 🎉 However, this is causing other problems: for example, Webpack watch compilation is not working on Windows, I think it's related.
  • Watch compilation using the code from your fork is faster and safer (it always shows whether an error happens in another file because of a change), at least on macOS where it's working.
  • How can we pass other compiler options like the warning level or treating warnings as errors?

@ncave
Copy link
Collaborator Author

ncave commented Jan 31, 2019

@alfonsogarciacaro We can pass full project options instead, but then the question is do we pass it on InteractiveChecker construction, or on the parsing call, or both? And when it changes, do we want to invalidate all cache, or just some, or none? (there is a scenario that you add a file to a project and you don't want to recompile the whole thing just because of that, not sure how common that is). I guess we can separate the project file list from the rest of the options, that seems more flexible.
I'll fix the assembly name issue when I can, I also need to order properly the errors by file (they are a bit mixed right now).

@alfonsogarciacaro
Copy link
Member

alfonsogarciacaro commented Jan 31, 2019

Right now (in master) Fable just starts over when there's any change in the .fsproj so it's acceptable to do that. But I agree it makes sense to separate the file list from the rest of options to help optimization.

Also, now Fable creates the checker just once and reuses it every time. The options are passed when parsing the project (or a single file). But if it helps with the caches, it's ok for me to associate one checker with each project. Actually, this is how I'm doing it in the components branch.

As a note, sometimes a couple of independent projects can share one file as it happens with the REPL Worker. Not sure if that can affect caching.

I'll fix the assembly name issue when I can.

If the issue with the drive latter in the file names can be fixed too that'd be fantastic :)

@ncave
Copy link
Collaborator Author

ncave commented Jan 31, 2019

I'll fix the assembly name issue when I can.

I think I fxed it, get latest. You shoudn't need to remove the paths from references anymore, or remove .dll extensions. I tried to make it backwards compatible, if reference has no .dll extension, will add it, if there is, leave it as is.

@alfonsogarciacaro
Copy link
Member

Thanks @ncave! I will give it a try tomorrow... a new FCS package has been finally published so I need to give anonymous records a try ;)

About the issue with the file names on Windows. I'm totally puzzled. I browsed a bit your code and got suspicious of implicitIncludeDir but I tried to set it to different values and it didn't help. It's very weird, if I pass the file names without removing C: the returned Implementation Files miss some of them (always the same in every compilation) but I don't get what's the pattern for that 😕

@alfonsogarciacaro
Copy link
Member

No luck with anonymous records. Seems the expression tree wasn't updated so we still have to wait :/

I'm trying to get a better grip of the FCS code base. I run ParseAndCheckProject multiple times with latest FCS package, but it's still quite slow in watch compilations. @ncave Not sure why but your cache here it's much faster than the one from IncrementalBuilder.fs. BTW, how expensive is the hash source operation? I say it because Fable (and the REPL) already knows which files have change so it would be easier (and less prone to errors) to pass a structure like the following:

{ FilePath: string; FileContent: string; Version: int }

Then you can use file.FilePath, file.Version for the cache keys.

@ncave
Copy link
Collaborator Author

ncave commented Feb 1, 2019

@alfonsogarciacaro The cost of hashing the source is probably trivial, compared to everything else. IMO we still need to make sure the source didn't change somehow, and the hashing is not a faster way to do that but a less memory intensive way, as it does not keep sources as keys (similar to this).

Not sure why but your cache here it's much faster than the one from IncrementalBuilder.fs.

Thank you, I was going for simplicity and minimalism there (poor man's IncrementalBuilder :).

@alfonsogarciacaro
Copy link
Member

Unfortunately needs to keep the sources in memory to avoid to reread all of them from disk every time a new watch compilation is triggered, which kind of defeats the purpose. Maybe the sources could be lazy and we could pass an invalidate function from Fable? So only when the files as marked as invalidated, FCS retrieves the source. In the other case it just takes the cached results for that file.

The other alternative would be to pass null strings for the files we know that haven't changed, but these would be quite error-prone.

@ncave
Copy link
Collaborator Author

ncave commented Feb 1, 2019

@alfonsogarciacaro I'm not sure I understand what is the optimization you're going for, what is that change going to save or simplify vs the existing functionality. Perhaps an example will help.
My gut feeling is we should not be exporting the control over cache invalidation outside of the checker, except for full cache clear. If we know file changed, we call ParseAndCheckFileInProject, otherwise we don't and keep the previous typecheck result.

@alfonsogarciacaro
Copy link
Member

@ncave Nothing in particular. I'm just excited after testing Fable with your code 😄 The best part of web development is hot reloading and with Fable we've come pretty close to that. But using FCS for that it's been always a bit painful and I'm not entirely happy with the current solution: using ParseAndCheckProject when only one file has changed is slow, while using ParseAndCheckFileInProject forces us to keep a manual map of the dependencies of each file to recompile those too in order to detect errors (which can be slow sometimes too and doesn't always work). Your version of ParseAndCheckProject seems to fix these problems (fantastic job! 👏 :clap), thus my excitement 😸

I was just thinking aloud if there was still room for improvements, but it's not that important. I'm just trying to understand better what's going on in service_shim.fs. For example, you reparse the files whose content has changed, but the checkCache is only keyed by file name. How is it possible that you still catch errors happening in other files that haven't changed?

@ncave
Copy link
Collaborator Author

ncave commented Feb 2, 2019

@alfonsogarciacaro That's simple, all cached typecheck entries below the modified file are removed.
It's not perfect, it the sense that if project file lists are changing a lot between calls, there could in theory be some artifacts left over from previous projects. A better solution would be to copy the good entries, remove everything, then add them back, even though it will churn the cache.

@ncave
Copy link
Collaborator Author

ncave commented Feb 3, 2019

@alfonsogarciacaro I changed the typecheck cache to copy the good entries, remove everything, then add them back. Also, the project errors are now grouped by file and sorted ascending by line and column.

@alfonsogarciacaro
Copy link
Member

@ncave Awesome, thank you! Interesting, I really appreciate your explanations. So contrary to my intuition, parsing takes much longer than type checking and the secret of your technique is separating the parsed and type checked caches so you can make the former more efficient 💪

@ncave
Copy link
Collaborator Author

ncave commented Feb 5, 2019

@alfonsogarciacaro I'm not sure why it's happening, but it's easy to fix, just remove the colon from the file name before sending it to the checker, i.e. .Replace(":", "")

@ncave
Copy link
Collaborator Author

ncave commented Feb 7, 2019

I've become a bit obsessed about using your poor man incremental builder in .NET too

@alfonsogarciacaro Alright, I created a new FCS branch just for you to experiment with :). It adds the InteractiveChecker in service_slim.fs and nothing else (dotnet only). The only (very minor) change vs stock FCS was to enable some constructors in service.fsi. There is a fcs-test project to test usage.
Hopefully this will enable you to play with different caching strategies, or just have fun with FCS ;)

@alfonsogarciacaro
Copy link
Member

@ncave It works and it's awesome :) I've published fable-compiler 2.2.0-beta using your second fork. Some of the watch compilations seem to be somewhat faster now but more importantly now users are always notified if a change causes an error in another file (sometimes these went missing if there was no a import dependency between the files in JS). Also, the code to deal with the state between watch compilations is simpler now 👍

I only had issues with the warnings, as the slim service is not filtering them by level. I added a custom filter that seems to work though it's currently ignoring the options from the .fsproj.

@nojaf
Copy link
Member

nojaf commented Feb 8, 2019

@alfonsogarciacaro did you try the sample with 2.2.0-beta-002? It's not working for me on Windows.

@alfonsogarciacaro
Copy link
Member

@nojaf Sorry, I only tested locally and didn't notice I had to change the assembly name when loaded from the package. Can you please try with 2.2.0-beta-004?

@ncave
Copy link
Collaborator Author

ncave commented Feb 8, 2019

I only had issues with the warnings, as the slim service is not filtering them by level.

It should, the default level is 3, every other warn-on or warn-off needs to come via options from the .fsproj (into FSharpProjectOptions).

@nojaf
Copy link
Member

nojaf commented Feb 8, 2019

@alfonsogarciacaro it works a like a charm.
2.2.0-beta-004 is very fast as well.

One little regression I think is

  <PropertyGroup>
    <!-- FS0025: Incomplete pattern matches on this expression. -->
    <WarningsAsErrors>25</WarningsAsErrors>
  </PropertyGroup>

It creates a warn log instead of an error. 2.1 does show the error.

@ncave
Copy link
Collaborator Author

ncave commented Feb 8, 2019

@alfonsogarciacaro @nojaf Seems like compiler warning options are properly applied to the parsing phase, but not to the typecheck phase logger. I'll look into it.

@alfonsogarciacaro
Copy link
Member

In the FCS service there's a function named ErrorHelpers.CreateErrorInfos that is applied after checking and filters the warnings. I tried to call it, but it needs another parameter PhasedDiagnostic that seems to be missing in the slim service.

@alfonsogarciacaro
Copy link
Member

@ncave Can the service_slim deal with signature .fsi files? I'm having issues to compile the REPL (now fable-standalone). It's something similar to what happened before, the implementation files returning by the checker are missing some entries (when there's a .fsi/.fs couple of files, it seems to discard the .fs). For example, SymbolHelpers.fs file cannot be located in the map of implementation files. But this time is happening both on Windows and Linux (Travis).

@alfonsogarciacaro
Copy link
Member

@ncave Seems to be an issue with the deduplication, if I comment out this line, then I can build the REPL.

I assume this is not a solution as it will likely cause problems in other situations, but I don't know what's the correct way to call this. The IncrementalBuilder does something similar to service_slim but in service.fs the return value of moduleNamesDict is discarded. I doubt that's the answer for us, because moduleNamesDict starts just as an empty Map.

@ncave
Copy link
Collaborator Author

ncave commented Feb 8, 2019

Seems to be an issue with the deduplication

@alfonsogarciacaro I'll take a look. Same code works perfectly fine in the other fork (the one with a lot of FABLE_COMPILER magic sprinkled on it :).

@ncave
Copy link
Collaborator Author

ncave commented Feb 9, 2019

@alfonsogarciacaro

  • I fixed the typecheck logger (to use compiler warning options). Also fixed FCS-Fable the same way.
  • The .fsi mapping issue might be on your end, since implementation files for files that have both .fs and .fsi will have their file name with .fsi (i.e. in the example above you should be looking for SymbolHelpers.fsi, not SymbolHelpers.fs).

@ncave
Copy link
Collaborator Author

ncave commented Feb 10, 2019

@alfonsogarciacaro
To maintan feature parity in FCS-Fable, I added an InteractiveChecker constructor that takes FSharpProjectOptions (the old constructor is still there):

InteractiveChecker.Create(references: string[], readAllBytes: string -> byte[], defines: string[], optimize: bool)
InteractiveChecker.Create(readAllBytes: string -> byte[], options: FSharpProjectOptions)

@alfonsogarciacaro
Copy link
Member

@ncave Awesome, thanks a lot! Fable standalone is building now in Appveyor for the components branch 🎉

  • The .fsi mapping issue might be on your end, since implementation files for files that have both .fs and .fsi will have their file name with .fsi

Interesting. Seems a bit counter intuitive as the implementation files should be the .fs ones (and I wonder why it was working before). In any case I fixed it following your suggestion and it's working now, thanks again!

@nojaf
Copy link
Member

nojaf commented Feb 12, 2019

  <PropertyGroup>
    <!-- FS0025: Incomplete pattern matches on this expression. -->
    <WarningsAsErrors>25</WarningsAsErrors>
  </PropertyGroup>

works again with 2.2.0-beta-006, I see the red errors, but I think it works a bit too well.
Problem I now have is that there is an incomplete pattern match in .fable/Fable.React.4.0.1/Fable.Helpers.ReactServer.fs(50,8):. As this is not my code I can't really fix this as an end-user.

With 2.1 my code compiles, even though Fable.React has an incomplete pattern match.

@alfonsogarciacaro
Copy link
Member

Hmm, strange. Fable is supposed to hide warnings from files in .fable folder and I didn't touch that part 🤔

@ncave
Copy link
Collaborator Author

ncave commented Feb 12, 2019

@alfonsogarciacaro Is it because those warnings are converted to errors, and Fable is compiling the "pre-compiled" packages with the same compiler options? (<WarningsAsErrors>25</WarningsAsErrors>)
Do .fable packages contain the project file as well (so we can compile with the original options), or just the source? If they don't and we can't, perhaps we can compile .fable packages with default options.

@alfonsogarciacaro
Copy link
Member

alfonsogarciacaro commented Feb 12, 2019

@ncave Packages in .fable folder are not precompiled, I'm only moving them there because Webpack has problems to locate npm packages from files that are outside the directory containing the package.json. The .fsproj files are kept but Fable is only doing a very simplistic resolution in that case (basically only getting the source files) and they're not compiled independently. Fable merges all sources in a big project before sending it to the F# compiler.

@ncave
Copy link
Collaborator Author

ncave commented Feb 12, 2019

@alfonsogarciacaro Thanks for the information.

@nojaf Looks like you have to use compiler options that work for all the components you use, since they all get compiled as one big project.

@alfonsogarciacaro
Copy link
Member

BTW, one of the reasons to merge everything in a single project is because is not possible (or at least I didn't manage to do it) to inline functions across different projects. Fable first versions had this issue.

@nojaf
Copy link
Member

nojaf commented Feb 13, 2019

So did Fable 2.1 also merge to one project? If not that would explain the change in behaviour if so I think we are missing something here.

@alfonsogarciacaro
Copy link
Member

Sources are being merged in one single project since Fable 1 if I remember correctly :) Anyways, I think there's something different going on here, because the ReactServer file is surrounded with #if !FABLE_COMPILER directives so in principle it should be ignored.

How are you compiling the project? If using fable-splitter you can pass fable: { cli: { verbose: true } } in the options to see the full list of arguments passed to the F# compiler.

@nojaf
Copy link
Member

nojaf commented Feb 13, 2019

I'm using fable-loader. The log below shows starting without errors in my code.
Then I add another case to a DU. An suddenly the errors in Fable.React also pop up.
When I fixed my own code, the Fable React errors remain.

Fable log
fable-compiler 2.2.0-beta-006
C:\temp\fable2-samples\minimal\src> dotnet restore App.fsproj
  Restoring packages for C:\temp\fable2-samples\minimal\src\App.fsproj...
  Generating MSBuild file C:\temp\fable2-samples\minimal\src\obj\App.fsproj.nuget.g.props.
  Restore completed in 234.1 ms for C:\temp\fable2-samples\minimal\src\App.fsproj.


fable-library: C:\temp\fable2-samples\minimal\node_modules\fable-compiler\bin\fable-library
F# PROJECT: ./src/App.fsproj
   --noframework
   --nologo
   --simpleresolution
   --nocopyfsharpcore
   --define:FABLE_COMPILER
   --define:DEBUG
   --optimize-
   --warn:3
   --fullpaths
   --flaterrors
   --target:library
   --targetprofile:netstandard
   --warnaserror:25,76
   -r:C:/Users/SIDFLOV/.nuget/packages/netstandard.library/2.0.3/build/netstandard2.0/ref/System.ValueTuple.dll
   -r:C:/Users/SIDFLOV/.nuget/packages/netstandard.library/2.0.3/build/netstandard2.0/ref/System.Threading.Tasks.dll
   -r:C:/Users/SIDFLOV/.nuget/packages/netstandard.library/2.0.3/build/netstandard2.0/ref/System.Threading.dll
   -r:C:/Users/SIDFLOV/.nuget/packages/netstandard.library/2.0.3/build/netstandard2.0/ref/System.Text.RegularExpressions.dll
   -r:C:/Users/SIDFLOV/.nuget/packages/netstandard.library/2.0.3/build/netstandard2.0/ref/System.Text.Encoding.Extensions.dll
   -r:C:/Users/SIDFLOV/.nuget/packages/netstandard.library/2.0.3/build/netstandard2.0/ref/System.Text.Encoding.dll
   -r:C:/Users/SIDFLOV/.nuget/packages/netstandard.library/2.0.3/build/netstandard2.0/ref/System.Runtime.Numerics.dll
   -r:C:/Users/SIDFLOV/.nuget/packages/netstandard.library/2.0.3/build/netstandard2.0/ref/System.Runtime.Extensions.dll
   -r:C:/Users/SIDFLOV/.nuget/packages/netstandard.library/2.0.3/build/netstandard2.0/ref/System.Runtime.dll
   -r:C:/Users/SIDFLOV/.nuget/packages/netstandard.library/2.0.3/build/netstandard2.0/ref/System.Reflection.Primitives.dll
   -r:C:/Users/SIDFLOV/.nuget/packages/netstandard.library/2.0.3/build/netstandard2.0/ref/System.Reflection.Extensions.dll
   -r:C:/Users/SIDFLOV/.nuget/packages/netstandard.library/2.0.3/build/netstandard2.0/ref/System.Reflection.dll
   -r:C:/Users/SIDFLOV/.nuget/packages/netstandard.library/2.0.3/build/netstandard2.0/ref/System.Numerics.dll
   -r:C:/Users/SIDFLOV/.nuget/packages/netstandard.library/2.0.3/build/netstandard2.0/ref/System.IO.dll
   -r:C:/Users/SIDFLOV/.nuget/packages/netstandard.library/2.0.3/build/netstandard2.0/ref/System.dll
   -r:C:/Users/SIDFLOV/.nuget/packages/netstandard.library/2.0.3/build/netstandard2.0/ref/System.Diagnostics.Tracing.dll
   -r:C:/Users/SIDFLOV/.nuget/packages/netstandard.library/2.0.3/build/netstandard2.0/ref/System.Diagnostics.Debug.dll
   -r:C:/Users/SIDFLOV/.nuget/packages/netstandard.library/2.0.3/build/netstandard2.0/ref/System.Core.dll
   -r:C:/Users/SIDFLOV/.nuget/packages/netstandard.library/2.0.3/build/netstandard2.0/ref/System.Console.dll
   -r:C:/Users/SIDFLOV/.nuget/packages/netstandard.library/2.0.3/build/netstandard2.0/ref/System.ComponentModel.TypeConverter.dll
   -r:C:/Users/SIDFLOV/.nuget/packages/netstandard.library/2.0.3/build/netstandard2.0/ref/System.ComponentModel.Primitives.dll
   -r:C:/Users/SIDFLOV/.nuget/packages/netstandard.library/2.0.3/build/netstandard2.0/ref/System.ComponentModel.dll
   -r:C:/Users/SIDFLOV/.nuget/packages/netstandard.library/2.0.3/build/netstandard2.0/ref/System.Collections.dll
   -r:C:/Users/SIDFLOV/.nuget/packages/netstandard.library/2.0.3/build/netstandard2.0/ref/System.Collections.Concurrent.dll
   -r:C:/Users/SIDFLOV/.nuget/packages/netstandard.library/2.0.3/build/netstandard2.0/ref/netstandard.dll
   -r:C:/Users/SIDFLOV/.nuget/packages/netstandard.library/2.0.3/build/netstandard2.0/ref/mscorlib.dll
   -r:C:/Users/SIDFLOV/.nuget/packages/fsharp.core/4.5.2/lib/netstandard1.6/FSharp.Core.dll
   -r:C:/Users/SIDFLOV/.nuget/packages/fable.import.browser/1.3.0/lib/netstandard1.6/Fable.Import.Browser.dll
   -r:C:/Users/SIDFLOV/.nuget/packages/fable.core/2.0.2/lib/netstandard2.0/Fable.Core.dll
   C:/temp/fable2-samples/minimal/.fable/Fable.React.4.0.1/Fable.Import.React.fs
   C:/temp/fable2-samples/minimal/.fable/Fable.React.4.0.1/Fable.Helpers.React.fs
   C:/temp/fable2-samples/minimal/.fable/Fable.React.4.0.1/Fable.Helpers.Isomorphic.fs
   C:/temp/fable2-samples/minimal/.fable/Fable.React.4.0.1/Fable.Helpers.ReactServer.fs
   C:/temp/fable2-samples/minimal/.fable/Thoth.Json.2.0.0/Decode.fs
   C:/temp/fable2-samples/minimal/.fable/Thoth.Json.2.0.0/Encode.fs
   C:/temp/fable2-samples/minimal/.fable/Fable.PowerPack.2.0.1/Keyboard.fs
   C:/temp/fable2-samples/minimal/.fable/Fable.PowerPack.2.0.1/BrowserStorage.fs
   C:/temp/fable2-samples/minimal/.fable/Fable.PowerPack.2.0.1/Result.fs
   C:/temp/fable2-samples/minimal/.fable/Fable.PowerPack.2.0.1/Promise.fs
   C:/temp/fable2-samples/minimal/.fable/Fable.PowerPack.2.0.1/Fetch.fs
   C:/temp/fable2-samples/minimal/.fable/Fable.PowerPack.2.0.1/extra/PromiseSeq/Type.fs
   C:/temp/fable2-samples/minimal/.fable/Fable.PowerPack.2.0.1/extra/PromiseSeq/Module.fs
   C:/temp/fable2-samples/minimal/.fable/Fable.PowerPack.2.0.1/extra/PromiseSeq/Extensions.fs
   C:/temp/fable2-samples/minimal/.fable/Fable.PowerPack.2.0.1/extra/Date/Local.fs
   C:/temp/fable2-samples/minimal/.fable/Fable.PowerPack.2.0.1/extra/Date/Format.fs
   C:/temp/fable2-samples/minimal/.fable/Fable.PowerPack.2.0.1/extra/IndexedDB.fs
   C:/temp/fable2-samples/minimal/.fable/Fable.Elmish.2.0.0/prelude.fs
   C:/temp/fable2-samples/minimal/.fable/Fable.Elmish.2.0.0/cmd.fs
   C:/temp/fable2-samples/minimal/.fable/Fable.Elmish.2.0.0/program.fs
   C:/temp/fable2-samples/minimal/.fable/Fable.Elmish.React.2.1.0/common.fs
   C:/temp/fable2-samples/minimal/.fable/Fable.Elmish.React.2.1.0/react.fs
   C:/temp/fable2-samples/minimal/.fable/Fable.Elmish.React.2.1.0/react-native.fs
   C:/temp/fable2-samples/minimal/src/Types.fs
   C:/temp/fable2-samples/minimal/src/State.fs
   C:/temp/fable2-samples/minimal/src/View.fs
   C:/temp/fable2-samples/minimal/src/App.fs
Parsing ./src/App.fsproj...
fable: Compiled src\App.fsproj
fable: Compiled src\App.fs
fable: Compiled src\State.fs
fable: Compiled src\View.fs
fable: Compiled .fable\Fable.Elmish.React.2.1.0\react.fs
fable: Compiled .fable\Fable.Elmish.2.0.0\program.fs
fable: Compiled src\Types.fs
fable: Compiled .fable\Fable.Elmish.2.0.0\prelude.fs
fable: Compiled .fable\Fable.Elmish.2.0.0\cmd.fs
fable: Compiled .fable\Fable.Elmish.React.2.1.0\common.fs
‼ 「wdm」: Hash: b6dc7cfc9e15a14de7ce
Version: webpack 4.29.3
Time: 13597ms
Built at: 02/13/2019 11:02:33 AM
    Asset      Size  Chunks             Chunk Names
bundle.js  1.68 MiB    main  [emitted]  main
Entrypoint main = bundle.js
[0] multi (webpack)-dev-server/client?http://localhost:8080 ./src/App.fsproj 40 bytes {main} [built]
[./.fable/Fable.Elmish.2.0.0/program.fs] 5.51 KiB {main} [built]
[./.fable/Fable.Elmish.React.2.1.0/react.fs] 2.49 KiB {main} [built]
[./node_modules/ansi-html/index.js] C:/Temp/fable2-samples/minimal/node_modules/ansi-html/index.js 4.16 KiB {main} [built]
[./node_modules/ansi-regex/index.js] C:/Temp/fable2-samples/minimal/node_modules/ansi-regex/index.js 135 bytes {main} [built]
[./node_modules/loglevel/lib/loglevel.js] C:/Temp/fable2-samples/minimal/node_modules/loglevel/lib/loglevel.js 7.68 KiB {main} [built]
[./node_modules/strip-ansi/index.js] C:/Temp/fable2-samples/minimal/node_modules/strip-ansi/index.js 161 bytes {main} [built]
[./node_modules/url/url.js] C:/Temp/fable2-samples/minimal/node_modules/url/url.js 22.8 KiB {main} [built]
[./node_modules/webpack-dev-server/client/index.js?http://localhost:8080] (webpack)-dev-server/client?http://localhost:8080 7.78 KiB {main} [built]
[./node_modules/webpack-dev-server/client/overlay.js] (webpack)-dev-server/client/overlay.js 3.58 KiB {main} [built]
[./node_modules/webpack-dev-server/client/socket.js] (webpack)-dev-server/client/socket.js 1.05 KiB {main} [built]
[./node_modules/webpack/hot sync ^\.\/log$] (webpack)/hot sync nonrecursive ^\.\/log$ 170 bytes {main} [built]
[./node_modules/webpack/hot/emitter.js] (webpack)/hot/emitter.js 75 bytes {main} [built]
[./src/App.fs] 790 bytes {main} [built]
[./src/App.fsproj] 25 bytes {main} [built]
    + 49 hidden modules

WARNING in (webpack)/buildin/global.js
There are multiple modules with names that only differ in casing.
This can lead to unexpected behavior when compiling on a filesystem with other case-semantic.
Use equal casing. Compare these module identifiers:
* C:\Temp\fable2-samples\minimal\node_modules\webpack\buildin\global.js
    Used by 2 module(s), i. e.
    C:\Temp\fable2-samples\minimal\node_modules\node-libs-browser\node_modules\punycode\punycode.js
* C:\temp\fable2-samples\minimal\node_modules\webpack\buildin\global.js
    Used by 1 module(s), i. e.
    C:\temp\fable2-samples\minimal\node_modules\scheduler\cjs\scheduler.development.js
 @ (webpack)/buildin/global.js
 @ C:/Temp/fable2-samples/minimal/node_modules/node-libs-browser/node_modules/punycode/punycode.js
 @ C:/Temp/fable2-samples/minimal/node_modules/url/url.js
 @ (webpack)-dev-server/client?http://localhost:8080
 @ multi (webpack)-dev-server/client?http://localhost:8080 ./src/App.fsproj
i 「wdm」: Compiled with warnings.
i 「wdm」: Compiling...
Parsing ./src/App.fsproj...
fable: Compiled src\Types.fs
× 「wdm」: Hash: 31881d1fafe5ae7c3ae3
Version: webpack 4.29.3
Time: 88ms
Built at: 02/13/2019 11:02:55 AM
    Asset      Size  Chunks             Chunk Names
bundle.js  1.68 MiB    main  [emitted]  main
Entrypoint main = bundle.js
[./src/Types.fs] 401 bytes {main} [not cacheable] [built] [4 errors]
    + 63 hidden modules

WARNING in (webpack)/buildin/global.js
There are multiple modules with names that only differ in casing.
This can lead to unexpected behavior when compiling on a filesystem with other case-semantic.
Use equal casing. Compare these module identifiers:
* C:\Temp\fable2-samples\minimal\node_modules\webpack\buildin\global.js
    Used by 2 module(s), i. e.
    C:\Temp\fable2-samples\minimal\node_modules\node-libs-browser\node_modules\punycode\punycode.js
* C:\temp\fable2-samples\minimal\node_modules\webpack\buildin\global.js
    Used by 1 module(s), i. e.
    C:\temp\fable2-samples\minimal\node_modules\scheduler\cjs\scheduler.development.js
 @ (webpack)/buildin/global.js
 @ C:/Temp/fable2-samples/minimal/node_modules/node-libs-browser/node_modules/punycode/punycode.js
 @ C:/Temp/fable2-samples/minimal/node_modules/url/url.js
 @ (webpack)-dev-server/client?http://localhost:8080
 @ multi (webpack)-dev-server/client?http://localhost:8080 ./src/App.fsproj

ERROR in ./src/Types.fs
Module Error (from ./node_modules/fable-loader/index.js):
C:/temp/fable2-samples/minimal/.fable/Fable.React.4.0.1/Fable.Helpers.ReactServer.fs(471,8): (471,12) error FSHARP: Incomplete pattern matches on this expression. For example, the value 'Custom (_, _)' may indicate a case not covered by the pattern(s). (code 25)
 @ ./src/View.fs 1:0-66 7:19-22 11:19-22
 @ ./src/App.fs
 @ ./src/App.fsproj
 @ multi (webpack)-dev-server/client?http://localhost:8080 ./src/App.fsproj

ERROR in ./src/Types.fs
Module Error (from ./node_modules/fable-loader/index.js):
C:/temp/fable2-samples/minimal/.fable/Fable.React.4.0.1/Fable.Helpers.ReactServer.fs(50,8): (50,12) error FSHARP: Incomplete pattern matches on this expression. For example, the value 'Custom (_, _)' may indicate a case not covered by the pattern(s). (code 25)
 @ ./src/View.fs 1:0-66 7:19-22 11:19-22
 @ ./src/App.fs
 @ ./src/App.fsproj
 @ multi (webpack)-dev-server/client?http://localhost:8080 ./src/App.fsproj

ERROR in ./src/Types.fs
Module Error (from ./node_modules/fable-loader/index.js):
C:/temp/fable2-samples/minimal/.fable/Fable.React.4.0.1/Fable.Helpers.ReactServer.fs(631,8): (631,12) error FSHARP: Incomplete pattern matches on this expression. For example, the value 'Custom (_, _)' may indicate a case not covered by the pattern(s). (code 25)
 @ ./src/View.fs 1:0-66 7:19-22 11:19-22
 @ ./src/App.fs
 @ ./src/App.fsproj
 @ multi (webpack)-dev-server/client?http://localhost:8080 ./src/App.fsproj

ERROR in ./src/Types.fs
Module Error (from ./node_modules/fable-loader/index.js):
C:/temp/fable2-samples/minimal/src/State.fs(8,10): (8,13) error FSHARP: Incomplete pattern matches on this expression. For example, the value 'Rise' may indicate a case not covered by the pattern(s). (code 25)
 @ ./src/View.fs 1:0-66 7:19-22 11:19-22
 @ ./src/App.fs
 @ ./src/App.fsproj
 @ multi (webpack)-dev-server/client?http://localhost:8080 ./src/App.fsproj
i 「wdm」: Failed to compile.
i 「wdm」: Compiling...
Parsing ./src/App.fsproj...
fable: Compiled src\Types.fs
× 「wdm」: Hash: 1ff4e47b9066a69a8978
Version: webpack 4.29.3
Time: 55ms
Built at: 02/13/2019 11:03:02 AM
    Asset      Size  Chunks             Chunk Names
bundle.js  1.68 MiB    main  [emitted]  main
Entrypoint main = bundle.js
[./src/Types.fs] 393 bytes {main} [not cacheable] [built] [3 errors]
    + 63 hidden modules

WARNING in (webpack)/buildin/global.js
There are multiple modules with names that only differ in casing.
This can lead to unexpected behavior when compiling on a filesystem with other case-semantic.
Use equal casing. Compare these module identifiers:
* C:\Temp\fable2-samples\minimal\node_modules\webpack\buildin\global.js
    Used by 2 module(s), i. e.
    C:\Temp\fable2-samples\minimal\node_modules\node-libs-browser\node_modules\punycode\punycode.js
* C:\temp\fable2-samples\minimal\node_modules\webpack\buildin\global.js
    Used by 1 module(s), i. e.
    C:\temp\fable2-samples\minimal\node_modules\scheduler\cjs\scheduler.development.js
 @ (webpack)/buildin/global.js
 @ C:/Temp/fable2-samples/minimal/node_modules/node-libs-browser/node_modules/punycode/punycode.js
 @ C:/Temp/fable2-samples/minimal/node_modules/url/url.js
 @ (webpack)-dev-server/client?http://localhost:8080
 @ multi (webpack)-dev-server/client?http://localhost:8080 ./src/App.fsproj

ERROR in ./src/Types.fs
Module Error (from ./node_modules/fable-loader/index.js):
C:/temp/fable2-samples/minimal/.fable/Fable.React.4.0.1/Fable.Helpers.ReactServer.fs(471,8): (471,12) error FSHARP: Incomplete pattern matches on this expression. For example, the value 'Custom (_, _)' may indicate a case not covered by the pattern(s). (code 25)
 @ ./src/View.fs 1:0-66 7:19-22 11:19-22
 @ ./src/App.fs
 @ ./src/App.fsproj
 @ multi (webpack)-dev-server/client?http://localhost:8080 ./src/App.fsproj

ERROR in ./src/Types.fs
Module Error (from ./node_modules/fable-loader/index.js):
C:/temp/fable2-samples/minimal/.fable/Fable.React.4.0.1/Fable.Helpers.ReactServer.fs(50,8): (50,12) error FSHARP: Incomplete pattern matches on this expression. For example, the value 'Custom (_, _)' may indicate a case not covered by the pattern(s). (code 25)
 @ ./src/View.fs 1:0-66 7:19-22 11:19-22
 @ ./src/App.fs
 @ ./src/App.fsproj
 @ multi (webpack)-dev-server/client?http://localhost:8080 ./src/App.fsproj

ERROR in ./src/Types.fs
Module Error (from ./node_modules/fable-loader/index.js):
C:/temp/fable2-samples/minimal/.fable/Fable.React.4.0.1/Fable.Helpers.ReactServer.fs(631,8): (631,12) error FSHARP: Incomplete pattern matches on this expression. For example, the value 'Custom (_, _)' may indicate a case not covered by the pattern(s). (code 25)
 @ ./src/View.fs 1:0-66 7:19-22 11:19-22
 @ ./src/App.fs
 @ ./src/App.fsproj
 @ multi (webpack)-dev-server/client?http://localhost:8080 ./src/App.fsproj
i 「wdm」: Failed to compile.

@alfonsogarciacaro
Copy link
Member

The log above shows starting without errors in my code. Then I add another case to a DU. And suddenly the errors in Fable.React also pop up.

Ah, so this only happens in watch compilations! You should have started from there ;) It may be that some project options are not honored in watch compilations, let me check...

@alfonsogarciacaro
Copy link
Member

@nojaf I cannot reproduce...

@nojaf
Copy link
Member

nojaf commented Feb 13, 2019

Minimal repro: https://github.com/nojaf/fable-2.2-beta-repro
If that works for you then I guess not an issue indeed.

@alfonsogarciacaro
Copy link
Member

Thanks @nojaf! I can reproduce and understand the issue now 👍 Can you please check if the latest beta fixes it?

@nojaf
Copy link
Member

nojaf commented Feb 13, 2019

Beta 007 fixes the issue, many thanks!

@ncave ncave mentioned this pull request Sep 7, 2021
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