-
Notifications
You must be signed in to change notification settings - Fork 793
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
Fix error list unification #3071
Conversation
I wanted to add @saul and @srivatsn as reviewers here but for some reason they aren't selectable - @KevinRansom do we have to add them as project collaborators? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good - I love seeing huge swathes of code deleted! 😄 Just got a few comments.
@@ -43,7 +43,7 @@ | |||
<Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform> | |||
<OutputType>Library</OutputType> | |||
<AppDesignerFolder>Properties</AppDesignerFolder> | |||
<VSRootSuffix>FSharpDev</VSRootSuffix> | |||
<VSRootSuffix>RoslynDev</VSRootSuffix> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Whoa this is wrong! Or we could merge FSharpDev with RoslynDev? I'm not massively fussed - it will help with cross-project dev.
@@ -43,7 +43,7 @@ | |||
<Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform> | |||
<OutputType>Library</OutputType> | |||
<AppDesignerFolder>Properties</AppDesignerFolder> | |||
<VSRootSuffix>FSharpDev</VSRootSuffix> | |||
<VSRootSuffix>RoslynDev</VSRootSuffix> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same here
@@ -112,16 +112,16 @@ type FSharpChecker with | |||
if func.IsProperty then | |||
let fullNames = | |||
[| if func.HasGetterMethod then | |||
yield func.GetterMethod.EnclosingEntity.TryGetFullName() | |||
yield func.GetterMethod.EnclosingEntity.Value.TryGetFullName() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we sure this isn't going to blow up?
// remove all Project System tasks from the task list, add everything else to the task set | ||
taskReporter.ClearAllTasks(); | ||
if (errorReporter != null) { | ||
//UIThread.Run(delegate () |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this need to run on the UI thread? Can this comment be removed?
{ | ||
this.taskProvider.Tasks.Add(task); | ||
errorReporter.ReportError2(taskText, errorCode, (VSTASKPRIORITY) priority, span.iStartLine, span.iStartIndex, span.iEndLine, span.iEndIndex, file); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How are warnings handled? I'm not even sure that warnings show in the Error List anyway - just something to consider.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The "priority" indicates information/warning/error. I'll add a note to double check once the roslyn fix is in
@@ -382,16 +399,16 @@ namespace rec Microsoft.VisualStudio.FSharp.ProjectSystem | |||
member this.GetMostRecentLines(n:int) : string[] = | |||
GetToolWindowAsITestVFSI().GetMostRecentLines(n) | |||
|
|||
// Can we get rid of this now? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we're not calling anything here, then yes, this can go. Same with the registration for this IOleComponent
@@ -182,807 +182,5 @@ internal static void DoOnUIThread(Action callback) | |||
} | |||
} | |||
|
|||
// DocumentTask is associated with an IVsTextLineMarker in a specified document and |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we rename this file to UIThread.cs
now that it only contains the UIThread class?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't touch the old project system code except to delete stuff
OK, all reviewed. Now this just sits around until the Roslyn fix is available :) |
An odd error in CI, seems unrelated
|
@dsyme any update on this? This should be available in Roslyn binaries |
@saul I will get back to it. I've been away at a conference this week and I'll get back into engineering mode over the next few working days If you would like to finish it off please send an additional PR based on Pilchie's option #2 here: #3047 (comment) |
@saul I will leave it up to @brettfo as to whether we integrate in 15.3 branch or not. I'd like to but only very few fixes are being taken in that branch right now If it doesn't go into that branch then as soon as 15.3 is out we will update master to use the right 15.3 Roslyn binaries. Then we can go ahead and pull this. |
@dotnet-bot test Windows_NT Release_ci_part2 Build please |
@saul and @dsyme: Due to changing APIs, We try to not get into tight spots like this, but due to VS 15.0, 15.1, and 15.2 all reporting assembly versions of 15.0 and 15.3 reporting 15.3, we're in this mess. |
@brettfo It your call with @cartermp in the end (and may depend on whether we need to take it to VS ship room to get permission). Ideally this fix would go into 15.3 but the problem is that I can't validate the fix as I don't have a 15.3 on any machine (and I'm not sure getting 15.3.preview2 would help - I really need 15.3 preview 3) |
This is ready once we can assume 15.3 |
If we get this into 15.3, we'll have to roll it up with changes to the language service as a high-priority bug fix. Otherwise, this would have to go out via nightlies and later, 15.4. @Pilchie your thoughts? |
Now that 15.3 is out and master is using the fixed Roslyn binaries I've removed the WIP tag and I believe this is ready for commit However we should re-check that it fixes the error list problem and that no new problems have been introduced |
@dsyme I get this assertion when opening VisualFSharp.sln with your PR after a This is for FSharp.Compiler.Interactive.Settings, as that was the only project which failed to load after ignoring assertions |
That will be related to #3393 . What happens if you ignore the assert? |
I see. It's fine and the PR will build without that project. I cannot reproduce #3047 with this PR. I'm psuedo-randomly screwing around with code in Paket to see how it reacts. Nice and clean! |
@cartermp Thank you so much for doing that validation. @KevinRansom This is good to merge now |
Since @cartermp has validated this, I'm going to pull it. |
* try use roslyn build error reporter * undo changes * undo changes * undo changes * try use roslyn build error reporter * more work on unifying diagnostics * minimize diff * bang bang * code review feedback * remove old test
This fixes error list unification #3047.
See discussion on dotnet/roslyn#19561. This even appears to work for multi-line error messages (which I had expected to be problematic)
The technique is to hack the old FSharp.ProjectSystem.Base to use the Roslyn error-reporting mechanism rather than the hard-wired one there. Quite a lot of old project system code can be deleted as a result (we should probably keep deleting unused features from that code to help with the migration to http://github.com/dotnet/project-system)
This requires that Roslyn fix, so we have to see when that makes it in - hopefully soon! It is important to note that we will require the Roslyn fix to be in place, if not Visual Studio will crash when it hits the call to FailFast mentioned in that Roslyn thread.
Separately this makes the Symbol API's
EnclosingEntity
return an option, I may factor that out into a separate PRTo consider (I don't think these are blocking)