[Unused open declarations] Doesn't work correctly on interfaces

[dungpa]

1st repro:

2nd repro:

Link:

https://github.com/dungpa/PowerTools/blob/3ea3e5dea66231ef315ac50e6fbf2aafd933c3a4/tests/FSharpVSPowerTools.Tests/MockGeneralOptionsPage.fs

https://github.com/dungpa/PowerTools/blob/3ea3e5dea66231ef315ac50e6fbf2aafd933c3a4/tests/FSharpVSPowerTools.Tests/Mocks.fs

It might be the case that the AST walker doesn't go inside interface declarations.

[vasily-kirichenko]

I cannot build vs-tests branch:

L:\github\FSharpVSPowerTools\tests\TestUtilities\AzureUtility.cs(76,28,76,37): error CS1061: 'System.Management.Automation.PowerShell' does not contain a definition for 'HadErrors' and no extension method 'HadErrors' accepting a first argument of type 'System.Management.Automation.PowerShell' could be found (are you missing a using directive or an assembly reference?)
2>L:\github\FSharpVSPowerTools\tests\TestUtilities\AzureUtility.cs(95,28,95,37): error CS1061: 'System.Management.Automation.PowerShell' does not contain a definition for 'HadErrors' and no extension method 'HadErrors' accepting a first argument of type 'System.Management.Automation.PowerShell' could be found (are you missing a using directive or an assembly reference?)
1>C:\Program Files (x86)\Microsoft SDKs\F#\3.1\Framework\v4.0\Microsoft.FSharp.Targets(155,9): error : Build was canceled.

[vasily-kirichenko]

OMG

This is definitely a VFPT/FCS bug. What will we do with it?

[vasily-kirichenko]

Same thing with the second sample

[vasily-kirichenko]

Trying to go to definition

Maybe something went really wrong with assembly references?

[dungpa]

IGeneralOptionsPage is defined in a C# project, Go To Definition will not work obviously.

FCS doesn't have correct information on tooltips in this case. We can't do anything to improve that.

[vasily-kirichenko]

Do you think FCS never gives a proper tooltip for C# namespaces? I suspect this is a special case.

[vasily-kirichenko]

I checked on my solution at work, tooltips for C# namespaces are shown correctly.

[vasily-kirichenko]

I consider this as a bug in FCS and we should not make a work around for it.

[dungpa]

Shouldn't work around this. It would be good if we could create a standalone repro and report upstream.

[thinkbeforecoding]

I 've seen the same with Provided types:

 //File1.fs
module MyModule
type MyProvidedType = XmlProvider<"...">

//File2.fs
module Usage
open MyModule // it is grayed... should not !

let (t: MyProvidedType.SomeGeneratedType) = ...

[OkayX6]

How about that one? (SchemaProvider)

EDIT: this comment contains deprecated information.

[dungpa]

Please open a separate issue. We might have skipped symbols from provided types.

[OkayX6]

Actually this is the behavior of an old version of FS Power tools... Sorry for the noise guys, it was in my bug backlog for a long time!

[dungpa]

@OkayX6 Well, it would be better to file the bug when it first appears. It's going to save us maintenance efforts in the long run :-).

[jtmueller]

Every F# file that I open thinks that ALL open statements are unused.

[OkayX6]

Hey question: is there a way we could avoid false positives, at the price of not graying some open statements?

[vasily-kirichenko]

@jtmueller this is how it's supposed to work.

[dungpa]

@jtmueller I really appreciate if you could provide a minimal repro. If the internal state is corrupted, it will mark all open statements as unused. We should definitely fix that.

[jtmueller]

@dungpa I'll try to put together a minimal repro. So far I've just noticed that since the update every F# file in any project of a rather large solution greys-out all open statements and lights up the scrollbar. I haven't seen it work right anywhere, but I haven't taken the time to explore outside of my main solution. If it works in a trivial case, I'm going to have a hell of a time figuring out what's unique about my particular solution.

[vasily-kirichenko]

@jtmueller Try to delete all binaries and build the solution again. It should help.

[jtmueller]

Thanks Vasily, that did help - after I closed and restarted Visual Studio.

[enricosada]

@vasily-kirichenko i got the same problem building another project. the Powershell.HadErrors property was added in powershell v3 (system.manangement.automation). I installed powershell 3 and after that the project works, now visual studio resolve the reference using the 3.0.0.0 assembly instead of v 1.0.0.0.

Maybe is better to write it as 3.0.0.0 in the csproj, at least i can see i dont have the correct assembly referenced:

<Reference Include="System.Management.Automation, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL">
      <SpecificVersion>False</SpecificVersion>
    </Reference>

@dungpa you want a pr about that?

[dungpa]

@enricosada Sure. Please do so.