search

JetBrains / resharper-fsharp

F# support in JetBrains Rider
Apache License 2.0
326 stars 55 forks source link

FSharp.Compiler.Private files not showing #49

Open NatElkins opened 5 years ago

NatElkins commented 5 years ago

Repro:

  1. Checkout https://github.com/Microsoft/visualfsharp
  2. As per README.md, run sh ./build.sh.
  3. Let it do its thing.
  4. When it's done, open FSharp.sln in Rider.
  5. Look at FSharp.Compiler.Private in the Solution Explorer.
  6. Look at the source of the project file.

Majority of files are missing. Is that expected?

image

NatElkins commented 5 years ago

And I'm on macOS using 2019.1.

NatElkins commented 5 years ago

Also the files appear without issue using VS4Mac.

NatElkins commented 5 years ago

@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?

auduchinok commented 4 years ago

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.