Skip to content

Conversation

CyrusNajmabadi
Copy link
Member

Fixes #17259

@CyrusNajmabadi
Copy link
Member Author

@dotnet/roslyn-compiler ptal.

@333fred
Copy link
Member

333fred commented Oct 14, 2025

I'd think I'd rather see us call GetEntryPointAndDiagnostics from GetDiagnostics, rather than marking this as a build-only error.

@333fred
Copy link
Member

333fred commented Oct 14, 2025

Also, please don't forget to test VB here, I assume something similar may exist.

@AlekseyTs
Copy link
Contributor

I'd think I'd rather see us call GetEntryPointAndDiagnostics from GetDiagnostics, rather than marking this as a build-only error.

I will be fine if we start with making a simple change that reflects the current state of affairs with respect to when the error is reported. Changing at which compilation phase the error is reported could be done later if we have a strong case for that.

@333fred
Copy link
Member

333fred commented Oct 14, 2025

@AlekseyTs I'd argue that the original bug report is that case; @svick is confused why the error isn't showing up immediately. If that's not enough of a justification, then I don't know what would ever be enough of a justification.

@CyrusNajmabadi
Copy link
Member Author

my concerns with GetEntryPointAndDiagnostics are:

  1. is it expensive? i thought it would have to search the entire compilation
  2. can it be called for the diagnostics for a particular file? i would think this was a question asked of the whole compilation.

@333fred
Copy link
Member

333fred commented Oct 14, 2025

  1. Potentially, but since GetDiagnostics binds everything anyway, I don't really expect it to be that different.
  2. I don't think so, no, it would only be whole project.

@AlekseyTs
Copy link
Contributor

If that's not enough of a justification, then I don't know what would ever be enough of a justification.

Since the PR provided no explanation other than claiming that it fixed the issue, I assumed this change led to a desired IDE behavior. @CyrusNajmabadi could you please clarify?

@CyrusNajmabadi
Copy link
Member Author

Since the PR provided no explanation other than claiming that it fixed the issue, I assumed this change led to a desired IDE behavior.

Yes. It addresses things where build errors are not filtered out when you go to 'build + intellisense' errors. Right now they are filtered out because we think this is a 'live' diagnostic, and thus we don't show the actual build diagnostic sincce we think it would cause duplicate errors.

@AlekseyTs
Copy link
Contributor

AlekseyTs commented Oct 14, 2025

Since the PR provided no explanation other than claiming that it fixed the issue, I assumed this change led to a desired IDE behavior.

Yes. It addresses things where build errors are not filtered out when you go to 'build + intellisense' errors. Right now they are filtered out because we think this is a 'live' diagnostic, and thus we don't show the actual build diagnostic sincce we think it would cause duplicate errors.

Sorry, it is still not clear to me. In your opinion, will the user remain confused after the change or not?

@CyrusNajmabadi
Copy link
Member Author

I do not believe they will be confused.

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

Projects

None yet

Development

Successfully merging this pull request may close these issues.

"Entry point cannot be marked async" error not showing in Build + IntelliSense Error List

5 participants