Fsharp: Same file name across different folders fails the compilation with error FS0239

[et1975]

"An implementation of the file or module '%s' has already been given"
coming from:
https://github.com/Microsoft/visualfsharp/blob/d2915e6ffa0d852cb3002199e66ef83bd2e8d1d0/src/fsharp/CompileOps.fs#L5221

File is not a module and perhaps the compiler should take into account the folder it is in.

Repro steps

Create a project and organize it using following folder structure:

/folder1/a.fs
/folder1/b.fs
/folder2/a.fs
/folder2/b.fs

This kind of organization is beneficial for modelling certain problems and having to maintain different file names is a burden.

Expected behavior

It should compile.

Actual behavior

Even if the modules/namespaces defined by these files are different the compilation will still fail with FS0239

Known workarounds

Rename the files.

Related information

• Operating system: n/a
• Branch: n/a
• .NET Runtime, CoreCLR or Mono Version: Mono 4.8 (.NET4.6)
• Editing Tools (e.g. Visual Studio Version): n/a
• Links to F# RFCs or entries on https://github.com/fsharp/fslang-suggestions: none
• Links to performance testing scripts: n/a
• Indications of severity: Minor

[enricosada]

should work.
time ago there was a bug in VF# (so VS extension) about folder with same name, but i fixed that.
it continue to be a problem if you do

folder1/a.fs
folder2/b.fs
folder1/c.fs
folder2/d.fs

becaue treeview cannot render it because need to repeat folder2 twice (but vf# show a message about that)

can you build from command line the project using /v:n attribute? so is possibile to see fsc arguments

[enricosada]

I can repro.

e:\tempet\folder2\a.fs(3,1): error FS0239: An implementation of the file or module 'A' has already been given [e:\tempet\tempet.fsproj]
e:\tempet\folder2\b.fs(3,1): error FS0239: An implementation of the file or module 'B' has already been given [e:\tempet\tempet.fsproj]
Build FAILED.
e:\tempet\folder2\a.fs(3,1): error FS0239: An implementation of the file or module 'A' has already been given [e:\tempet\tempet.fsproj]
e:\tempet\folder2\b.fs(3,1): error FS0239: An implementation of the file or module 'B' has already been given [e:\tempet\tempet.fsproj]
    0 Warning(s)
    2 Error(s)

I added a repro with new fsproj, but is fsc who complains, i checked fsc args afaik are correct.

just unzip the repro

tempet.zip

dotnet restore
dotnet build -v n

fsc arguments are right

         ,,,
         E:\tempet\folder1\a.fs
         E:\tempet\folder1\b.fs
         E:\tempet\folder2\a.fs
         E:\tempet\folder2\b.fs

NOTE that modules are not called 'A' and 'B', but have a namespace and distinct module name inside /cc @KevinRansom

added a screenshot because now VSCode is amazing :D

[et1975]

Thanks for a quick fix folks, where can I find the fixed release?
Apparently the problem is exacerbated by the new Fable project system, same file name in a referenced dependency project is causing this error as well!
/cc @alfonsogarciacaro

[vasily-kirichenko]

@et1975 I've closed my fix PR because I cannot fix some tests.

[alfonsogarciacaro]

This is going to be a huge pain point for Fable if not fixed. At the moment we are merging all files (from every project) into a single project because this is the only (or at least easiest) way to get the full AST and inline functions across projects. As this is also a problem for .NET F# projects, I think it makes sense fixing it here instead of trying to find a workaround in Fable.

@dsyme @forki I'm trying to continue @vasily-kirichenko PR in #2728, but I need some guidance as I don't know the F# compiler code base very well. Some questions:

• It's the qnameOrder comparison function the only (obvious) place where identifiers for two files with same name (but different full path) can conflict? I've also tried to use something different than the filename in CanonicalizeFilename but it didn't seem to work.
• In #2686 @vasily-kirichenko comments qnameOrder shouldn't make a distinction between signature and implementation files. However, these files are split in two different data structures so they shouldn't conflict, is that right?
• Any other place worth looking at?

[daniellittledev]

This still seems to be affecting VS 15.5.4 (in some cases) and ionide (in all cases)

[haf]

This still happens in large projects while they are compiling in the background, in both VSCode and Rider.

[NullVoxPopuli]

I have this issue with VS 2017

[abelbraaksma]

@dsyme, could you reopen this, please? And perhaps also the related PR, as @alfonsogarciacaro mentioned there, it appears the fix didn't solve the issue: https://github.com/fsharp/FSharp.Compiler.Service/pull/748.

[NullVoxPopuli]

I have a way to easily replicate this:

• open: https://github.com/NullVoxPopuli/CryptoExchangeClient/tree/websocket-support in visual studio 2017 Community (on that specific branch)
• click run (examples project)
• notice build succeeds.
• stop debugging
• Open side-by-side
  
  
  
  • base_exchange/client/WebSocketClient.fs
  
  
  • exchanges/cobinhood/clients/WebSocketClient.fs
  
  

• Click around in both files, adding spaces in each one, saving after each change.
• After 30 seconds, the file that appears lower the compilation list exhibits the error.
• Closing and Re-opening Visual Studio is the only way to get rid of the error reliably.
• Building the project still succeeds.

[dsyme]

@NullVoxPopuli Thanks for the repro

[kspeakman]

As to severity. This bug strongly discourages using folders for organization. The errors generated are disruptive enough to force a change in project organization / naming strategy.

P.S. #nowarn "239" does nothing to prevent the error from displaying.

[kspeakman]

This continues to bite me in VS 2017 and 2019. It also has a subtle display bug in the Solution Explorer when you have a subfolder named the same as another subfolder in a different path.

__1__ Have to prefix certain files to avoid the error. Actually, just tried it and cannot replicate the error so far in 15.9.12.
__2__ Have to name the folder itself differently to avoid the display bug.

On the right you can see what happens if I name both subfolders "Handlers". It forces the folder to be displayed at the top even though this is not the compile order. It cannot be moved with Move Down. _All the files/modules within it are differently named from the other Handlers folder._

This is the compile order from the project file. It does not match the Solution Explorer display on the right.