Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open an .fs file in Dev 15 RC and it is not colourized #1756

Closed
KevinRansom opened this issue Nov 17, 2016 · 1 comment
Closed

Open an .fs file in Dev 15 RC and it is not colourized #1756

KevinRansom opened this issue Nov 17, 2016 · 1 comment
Labels
Bug Impact-High (Internal MS Team use only) Describes an issue with extreme impact on existing code.
Milestone

Comments

@KevinRansom
Copy link
Member

F# colourization works great when editing a file that is part of an F# project, but a loose .fs file does not get colourized.

Expected VS editor to edit loose F# files with full colorization etc ...

untitled

@KevinRansom KevinRansom added Area-IDE Project System Bug Impact-High (Internal MS Team use only) Describes an issue with extreme impact on existing code. labels Nov 17, 2016
@cartermp cartermp added this to the VS 2017 RTM milestone Nov 17, 2016
@dsyme
Copy link
Contributor

dsyme commented Nov 23, 2016

@brettfo I've fixed this here: #1819

@dsyme dsyme closed this as completed in 820af62 Nov 23, 2016
nosami pushed a commit to xamarin/visualfsharp that referenced this issue Jan 26, 2022
…dotnet#1819)

Fixes underlying issues associated with dotnet#1815

After getting a 15+ second UI block in VS 2017, I've done a complete review of the way the new LanguageService implementation is using FSharp.Compiler.Service (the DLL internally called FSharp.Compiler.LanguageService in the Visual F# Tools repo, but it's basically the same component as FCS)

In short, the new LS implementation expects FCS to honour cancellation of submitted tasks in a more timely way.  This PR greatly improves the cancellability of FCS requests, which was one of the underlying causes of such a long UI block.

1. Improve FCS so that it respects cancellation in a more timely way.  Cancellation will now be respected at each step of the evaluation of the incremental build graph (IncrementalBuild.fs). This represents a fundamental improvement to FCS which will be very useful to other F# editors as well, as long as they are cancelling tasks.

   In particular, some FCS requests could be _very_ long running, e.g. CheckFileInProject may require checking **all** the files prior to this file (and if cross-F#-to-F#-project checking is enabled then it will  require checking all the dependent projects too).  

   Prior to this PR FCS was not respecting cancellation of these requests, and was simply running them through and then throwing the results away.

2. The new LS implementation was using some unnecessary calls to Async.RunSynchronously.  All of these could inject arbitrary non-responsiveness into some part of the causality chains.  I've removed these in favour of fully async code.

3. In FCS the old IsResultObsolete logic can be removed in favour of checking a cancellation token

This also fixes dotnet#1756, see [this change here](https://github.com/Microsoft/visualfsharp/pull/1819/files#diff-69fa840cd1c6d144d0cd489cad82e901R88)

We have a separate issue that too may errors/warnings are shown for out-of-project files - the old LS implementation showed the first 3 errors - a good choice which we decided on long ago.  I'll add an issue for that.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Impact-High (Internal MS Team use only) Describes an issue with extreme impact on existing code.
Projects
None yet
Development

No branches or pull requests

4 participants