EmbeddedText/FsYacc/FsLex items in .NET SDK projects are not recognised

[dsyme]

The VS project system in 15.6/master seems to have a problem preparing correct arguments for new-style projects using EmbeddedText, FsLex, FsYacc items.

Compare these

            fcs\Fsharp.Compiler.Service.sln
            .\FSharp.sln

Both FSharp.Compiler.Service.fsproj (new stlye) and FSharp.Compiler.Private.fsproj (old style) has

<EmbeddedText Include="$(FSharpSourcesRoot)/fsharp/FSComp.txt">
  <Link>FSComp.txt</Link>
</EmbeddedText>

In an old-style project files the item appears:

In new-style project files the item is absent:

This seems to mean that the generated file does not get passed to FCS in Visual Studio. The same applies to files like pars.fs. The corresponding generated file does get passed when using command line msbuild:

msbuild C:\GitHub\dsyme\visualfsharp\fcs\FSharp.Compiler.Service\FSharp.Compiler.Service.fsproj

            … obj\Debug\netstandard2.0\FSComp.fs …

Compare these two similar scenarios:

1. open src\FSharp.Compiler.Service.fsproj (new-style projects), edit src\fsharp\symbols\Symbols.fs

against

1. open FSharp.sln (old-style projects), edit src\fsharp\symbols\Symbols.fs

The first takes 240seconds of CPU time to colorize. The second takes about 40 seconds (as expected).

It might be because the project is checked twice - one for netstandard2.0 and one for net45. But I thought that wasn't implemented. That would explain only half the difference, and colorization shouldn't be delayed.

There is also a difference in treatment of signature files which I will also investigate.

[dsyme]

This is caused by the fact that FSComp.fs is not being reported in the list of valid files. This causes a huge number of invalid-identifier errors to be reported in the background, including a lot of time spent in the background preparing suggestions for names (cc @forki)

The list of files FCS is getting is here: https://gist.github.com/dsyme/db118033ddf720bd23c25c91489b3f81

[dsyme]

@cartermp I updated the description

[auduchinok]

This is caused by the fact that FSComp.fs is not being reported in the list of valid files. This causes a huge number of invalid-identifier errors to be reported in the background, including a lot of time spent in the background preparing suggestions for names (cc @forki)

@dsyme I've checked what's coming from MSBuild invocation on the SDK-based project and files that are results of these targets do not appear there at all, there're only items that are passed to the targets itself.

Checking an older commit (before moving to SDK-based projects) shows these targets results files evaluated as CompileBefore items.

Checking current master if there're any CompileBefore items at all:

[auduchinok]

The corresponding generated file does get passed when using command line msbuild:

Probably additional targets should be triggered in IDEs, that aren't triggered now but triggered by MSBuild (e.g. if the build depends on it). It wasn't, however, needed in the old-style projects.
I'm looking what triggers them in console build.

[auduchinok]

OK, adding GenerateCode to the list of targets called on project load made FSComp.fs appear in Rider.

[auduchinok]

Both FSharp.Compiler.Service.fsproj (new stlye) and FSharp.Compiler.Private.fsproj (old style) has

<EmbeddedText Include="$(FSharpSourcesRoot)/fsharp/FSComp.txt">
  <Link>FSComp.txt</Link>
</EmbeddedText>

@dsyme That's wrong, in FCS these items are included in FsSrGen, not EmbeddedText, and it wasn't changed during transition to SDK-based projects:
https://github.com/Microsoft/visualfsharp/blob/f62158bae5a300be60abf3d97ae7cb4f83e7267d/fcs/FSharp.Compiler.Service/FSharp.Compiler.Service.fsproj#L48-L50

Re performance difference: when we had this problem with absence of FSComp.fs before, it was even worse, as had been seen in #3882.