-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
JavaScript interop source generator should emit #line directives pointing to the originating declaration #107577
Comments
Tagging subscribers to this area: @dotnet/interop-contrib |
If we were to emit line directives, how would that interact with stepping? A huge part of the choice to use source generators for interop was to be able to step through the generated code and see the C# for what's happening. Would it be possible to only emit line directives for the signature and not the body to get the right experience? |
Emitting it only for the signature wouldn't help. We don't have currently any means to make stepping work with |
I think a decent compromise here for the JavaScript generators would be to remap the line that defines the signature field back to the original declaration's line as there's no interesting code to step there and the rude edit error itself doesn't let you easily trace back to the original method. That way the rude edit would point to user code and stepping would still work. |
I guess we can try that. We would also want to remap all field definitions. That would likely cover most rude edits. |
Tagging subscribers to 'arch-wasm': @lewing |
Using the reproduction steps we're getting a slightly different error:
When we use
|
Description
The source generator emits non-user code methods without
#line
directives. That's usually ok, since the code is not expected to be stepped into or compiler errors are not expected to occur in it. However, changing the declaration of a partial method stub annotated by JSImport attribute during EnC/Hot Reload might result in rude edits. Currently, these diagnostics are reported with locations pointing to the source-generated file.Adding
#line
directives that map the locations back to the originating declaration would improve the experience. The IDE would then show the errors in the source file where the user is actually making the changes.Reproduction Steps
dotnet new blazorwasm -o testblazor01
cd testblazor01
testblazor01.csproj
add the following:Program.cs
, add the following at the end:Expected behavior
Actual behavior
Regression?
No
Known Workarounds
No response
Configuration
No response
Other information
No response
The text was updated successfully, but these errors were encountered: