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

Intellisense continues to highlight fixed/stale errors (only if they were in the last compile attempt) #3892

Open
Skyedra opened this issue Jul 4, 2020 · 2 comments

Comments

@Skyedra
Copy link

Skyedra commented Jul 4, 2020

Issue Description

If the last time you compiled there was a programming error, you will continue to observe the red underline indicating an error until you compile again. This is inconsistent behavior with the real-time detection between compiles, and leads to a confusing state.

The phantom error will also remain in the 'problems' window and file sidebar until recompile, even if fixed. After a recompile, the error is removed from both 'problems' and intellisense.

The incorrect underline persists if omnisharp is restarted, as well as if the file is closed and re-opened. However, if VS Code window is reloaded, the stale underline goes away.

Comparatively, Intellisense red underlines work normally for errors that are introduced and fixed between compiles. (Automatic flag & unflag of error in real-time). It's not until the error is compiled that it becomes persistent until the next compile.

Steps to Reproduce

  1. (Starting from a clean, compilable code base)
  2. Intentionally create an error, such as introducing a typo in the name of a class you are trying to instantiate.
  3. F5 to attempt a debug -- compile fails due to the type not being able to be found
  4. Click Abort to return to code
  5. Observe red underline showing the error
  6. Fix typo in class name
  7. Red underline is still visible with type error, despite the error having been fixed [BUG]
  8. Press F5 to attempt a second debug. Compile is OK and red underline now disappears.

Expected Behavior

Intellisense red underlines reflects the current, real-time state of the code.

Actual Behavior

Intellisense red underlines reflects an inconsistent state -- combining the errors (but not fixes) of the previous compile attempt plus additional any errors introduced since then. Since the errors update elsewhere, the developer expects the errors shown to be the current state of the code, and then spends time chasing after errors that are already fixed.

Logs

OmniSharp log

Post the output from Output-->OmniSharp log here

C# log

Post the output from Output-->C# here

Environment information

VSCode version: 1.46.1
C# Extension: 1.22.1

Mono Information OmniSharp using built-in mono
Dotnet Information .NET Core SDK (reflecting any global.json): Version: 3.1.301 Commit: 7feb845744

Runtime Environment:
OS Name: ubuntu
OS Version: 18.04
OS Platform: Linux
RID: ubuntu.18.04-x64
Base Path: /usr/share/dotnet/sdk/3.1.301/

Host (useful for support):
Version: 3.1.5
Commit: 65cd789777

.NET Core SDKs installed:
2.1.807 [/usr/share/dotnet/sdk]
3.1.301 [/usr/share/dotnet/sdk]

.NET Core runtimes installed:
Microsoft.AspNetCore.All 2.1.19 [/usr/share/dotnet/shared/Microsoft.AspNetCore.All]
Microsoft.AspNetCore.App 2.1.19 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 3.1.5 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 2.1.19 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 3.1.5 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:
https://aka.ms/dotnet-download

Visual Studio Code Extensions
Extension Author Version
codedox wiggin77 1.3.1
csharp ms-dotnettools 1.22.1
haxe-debug vshaxe 1.2.3
haxe-extension-pack vshaxe 1.3.0
haxe-hl HaxeFoundation 1.1.0
hxcpp-debugger vshaxe 1.2.4
svn-scm johnstoncode 2.11.4
vshaxe nadako 2.21.2
@SirIntruder
Copy link

I am not sure if c# extension can fix this on its own. Maybe this would be enough? microsoft/vscode#77214

@JoeRobich
Copy link
Member

As a workaround to stop reporting errors from the build task, you could update your tasks.json such that the "build" task doesn't define a problemMatcher.

example:

    {
      "label": "build",
      "command": "dotnet",
      "type": "process",
      "args": [
        "build",
        "${workspaceFolder}/src/dotnet-format.csproj",
        "/property:GenerateFullPaths=true",
        "/consoleloggerparameters:NoSummary"
      ],
-     "problemMatcher": "$msCompile"
+     "problemMatcher": []
    },

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants