resharper-fsharp
resharper-fsharp copied to clipboard
FSharp.Compiler.Private files not showing
Repro:
- Checkout
https://github.com/Microsoft/visualfsharp
- As per README.md, run
sh ./build.sh
. - Let it do its thing.
- When it's done, open FSharp.sln in Rider.
- Look at FSharp.Compiler.Private in the Solution Explorer.
- Look at the source of the project file.
Majority of files are missing. Is that expected?
And I'm on macOS using 2019.1.
Also the files appear without issue using VS4Mac.
@auduchinok This still appears to be an issue with the following version:
JetBrains Rider 2019.2.2
Build #RD-192.6584.65, built on August 28, 2019
Licensed to Masse / Nathaniel Elkins
Subscription is active until September 25, 2019
Runtime version: 11.0.3+12-b304.39 x86_64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
macOS 10.14.5
GC: ParNew, ConcurrentMarkSweep
Memory: 1450M
Cores: 12
Registry: ide.tree.horizontal.default.autoscrolling=false, performance.watcher.sampling.interval.ms=200, ide.borderless.title.product=false, performance.watcher.unresponsive.interval.ms=1000, ide.tooltip.initialDelay.highlighter=0, search.everywhere.settings=true, parameter.info.max.visible.rows=10, ide.win.file.chooser.native=true, ide.borderless.title.project.path=false, actionSystem.fix.alt.gr=false, search.everywhere.pattern.checking=false, ide.tooltip.initialDelay=0, ide.borderless.title.classpath=false, ide.require.transaction.for.model.changes=false, rider.enable.designer.winForms=false
Non-Bundled Plugins: IdeaVIM, io.protostuff.protostuff-jetbrains-plugin, net.seesharpsoft.intellij.plugins.csv, AWSCloudFormation
Any update on this?
There's a bit of MSBuild magic here and there in the compiler solution, along with additional support for working on FSharp.Core and referencing it as a project inside FCS itself. We likely need to add some special handling too.
As a workaround, it's possible to work on the compiler via fcs/FSharp.Compiler.Service.sln
solution, which contains most of the compiler code and references FSharp.Core as a compiled dll. Removing one of the target frameworks also significantly improves performance. There's no workaround for working on FSharp.Core for now if it doesn't work.