FS0039 - not defined - when VS is editing a new solution

[BentTranberg]

Message about identifier not defined - FS0039 - when VS edits a new solution. That is, VS has not yet been closed since the solution was created.

This issue easily and reliably reproduces every time, unlike some other issues related to FS0039. Hopefully it can get smashed in a flash, and maybe it's possible to get a grip on similar errors through this one. I've been waiting for that one for years => #3510

After reopening the solution with VS, the error message is gone, even if .vs and bin and obj is deleted before reopening.

Repro steps

1. Create a solution named Bug with an F# .NET Core Console Application named Bug.
2. Add file Bug.fs above Program.fs
3. Insert call to Bug.bug in main function.

This is what Bug.fs contains.

module Bug

    let bug () =
        ()

And the call in main looks like this.

    Bug.bug ()

The solution is attached. Please note that the solution is attached only to make it clear what it should look like, since there doesn't seem to be a way to make the error appear when opening an existing solution - so you just have to follow the steps to recreate the solution.

Bug.zip

Known workarounds

Close VS. Then reopen the solution. Error message is gone.

Other

Visual Studio 16.5.0

[dsyme]

I went through the steps and didn't repro this. If there was a problem I think it's been fixed.

[BentTranberg]

@dsyme and @cartermp, I am still able to reproduce this in VS 16.8.0 Preview 2.1 and VS 16.7.2, but possibly with a slight change in behaviour since my original report. Rebuilding twice is now a workaround, and I suspect that wasn't the case earlier, but I have no easy way to confirm that now.

1. I create the solution as described in the original issue report.

2. The error message stays in the Error List panel for several minutes, possibly forever - I wait around five minutes.

3. The error message only shows if Build + Intellisense or Intellisense Only is selected, but not when Build only is selected.

4. I do a Rebuild and wait, but the error message still doesn't go away after several minutes - possibly never.

5. Then I do a second Rebuild, and the error message disappear after just a few seconds.

edit: Of course this isn't an issue that bothers me at all, but I'm thinking perhaps you might still want it open because it looks like a reliable repro, and can give somebody a grip on the problem if it's worth fixing.

[cartermp]

I will re-open this. Generally speaking there's some issues with "sticky" errors in the error list. C# can similarly have the same issue, making me think this might not be entirely an F# tools thing.

[cartermp]

So a little bit of detail about the general problem space courtesy of @jmarolf

The issue really traces itself back to: MSBuild does not have a snapshot model. All MSBuild diagnostics in VS are created from scraping build output. Roslyn has a snapshot model and so understands when a diagnostic came from the current workspace or a previous one. MSBuild diagnostics come in whenever they please and may not have been produced for the current workspace. When do you clear stale MSBuild diagnostics? How do you know for certain they are stale?

The algorithm is supposed to be that diagnostics from MSBuild are ignored if a file has been edited “recently enough” and we prefer the diagnostic last from line analysis. But how do you know what is recent enough? MSBuild doesn’t tell us when it’s read the file for the purpose of compilation.

So it's a difficult space when the two error sources are mixed.

When Build Only is selected, you'll only see the MSBuild errors and that explains the consistent behavior there.

I would expect IntelliSense Only to be consistent, but if it's not then there is likely a subtle bug somewhere on our side.

Separately, #6036 may also be related, where a bug in not showing an IntelliSense error masks a build error.

So between this, #6036, and #3510 I think we have at least one bug on our end. But we could also be running into the kinds of issues mentioned.

[jkone27]

is this still open, and can it also affect this issue?
https://github.com/jkone27/test-broken

in that case the build completes, but the VS ide shows FS0039 errors

[ghost]

It is still a real problem

I create an empty file named first.fsx

With code

let a = 18

let b = 1200

then open dotnet fsi

with type into shell

> #load "first.fsx"
- open first;;
[正在加载 D:\workspace\netroby\dotnet\fsharp\first.fsx]
namespace FSI_0002
  val a : int
  val b : int


  open first;;
  -----^^^^^

stdin(2,6): error FS0039: 未定义命名空间或模块“first”。 你可能需要以下之一:
   First
   List

> first.a
- ;;

  first.a
  ^^^^^

stdin(3,1): error FS0039: 未定义值、命名空间、类型或模块“first”。 你可能需要以下之一:
   First
   fst
   List
   list

> open First;;
> First.a;
- ;;
val it : int = 18
```

I am not happy with it .  The filename was first.fsx.

Why it be `open First`, not  `open first`

I am not quite understand why force this action.

[dsyme]

Hello @cnmade,

This is by design, it has always been the default module name inference for F#, where module names are normally upper case.

You can add

module first

at the top of your file

[ghost]

@dsyme Thanks for let me know. I have not notice it because the document not clear description it.

https://docs.microsoft.com/en-us/dotnet/fsharp/tools/fsharp-interactive/#loading-other-scripts

I guess we can improve the document to description the rule:

The default Module name will be auto match the File Name, with Upper case by default.

If you do not want the default Upper case module name, You should add one line

module first

module then following by your own module name (lower case ) or what you want

[dsyme]

@cnmade Thank you , yes, I'll update the docs now

[dsyme]

@cnmade please review dotnet/docs#25297