Razor compiler does not generate C# for partial @using directives #7494
Labels
Comments
NTaylorMullen
referenced
this issue
Oct 14, 2021
- This is part 2/2 to fix `@using` statement completion in Razor files. Part 1 is over in the dotnet/roslyn repo: [PR](dotnet/roslyn#57160) - So the two components to this issue are as follows: 1. C# was throwing whenever they'd be in the process of returning `isIncomplete: true` completion lists and filter down to 0 items. This typically happened at the `n` of `@using`. Therefore things would explode preventing us from being able to control the completion experience 2. Found that the Razor compiler doesn't generate C# for `@using` statements. This means when we try to query what language exists at `@using|` it says "sorry nothing". My bet is that the compiler special cases C# keywords and preemptively doesn't generate C# for them. This means we bail out of our completion path entirely and return an empty completion list breaking the flow. That issue is tracked here: https://github.com/dotnet/aspnetcore/issues/37568 - Razor tooling wasn't directly responsible for the second issue; however, wes till needed to come up with a low-risk fix. The fix I landed on was to special case the bug and call it out specifically in code. The special case consists of three components: 1. Only check special cases if we failed to resolve a language. This is already a completion failure case so in the worst case we still don't provide completion 2. Detecting if we're in an `isIncomplete: true` scenario by looking at the trigger kind and seeing if it's `TriggerForIncompleteCompletions`next we look at the word span that's currently active 3. Detecting if the user is attempting to type a C# keyword (full match like `using` in `@using|`) - Given this fix is going to go through QB for dev17 I added insane amounts of tests/checks to ensure things are of the highest quality / we don't degrade functionality. ### Before  ### After  Fixes #5606
NTaylorMullen
referenced
this issue
Oct 14, 2021
- This is part 2/2 to fix `@using` statement completion in Razor files. Part 1 is over in the dotnet/roslyn repo: [PR](dotnet/roslyn#57160) - So the two components to this issue are as follows: 1. C# was throwing whenever they'd be in the process of returning `isIncomplete: true` completion lists and filter down to 0 items. This typically happened at the `n` of `@using`. Therefore things would explode preventing us from being able to control the completion experience 2. Found that the Razor compiler doesn't generate C# for `@using` statements. This means when we try to query what language exists at `@using|` it says "sorry nothing". My bet is that the compiler special cases C# keywords and preemptively doesn't generate C# for them. This means we bail out of our completion path entirely and return an empty completion list breaking the flow. That issue is tracked here: https://github.com/dotnet/aspnetcore/issues/37568 - Razor tooling wasn't directly responsible for the second issue; however, wes till needed to come up with a low-risk fix. The fix I landed on was to special case the bug and call it out specifically in code. The special case consists of three components: 1. Only check special cases if we failed to resolve a language. This is already a completion failure case so in the worst case we still don't provide completion 2. Detecting if we're in an `isIncomplete: true` scenario by looking at the trigger kind and seeing if it's `TriggerForIncompleteCompletions`next we look at the word span that's currently active 3. Detecting if the user is attempting to type a C# keyword (full match like `using` in `@using|`) - Given this fix is going to go through QB for dev17 I added insane amounts of tests/checks to ensure things are of the highest quality / we don't degrade functionality. ### Before  ### After  Fixes #5606
NTaylorMullen
referenced
this issue
Oct 14, 2021
- This is part 2/2 to fix `@using` statement completion in Razor files. Part 1 is over in the dotnet/roslyn repo: [PR](dotnet/roslyn#57160) - So the two components to this issue are as follows: 1. C# was throwing whenever they'd be in the process of returning `isIncomplete: true` completion lists and filter down to 0 items. This typically happened at the `n` of `@using`. Therefore things would explode preventing us from being able to control the completion experience 2. Found that the Razor compiler doesn't generate C# for `@using` statements. This means when we try to query what language exists at `@using|` it says "sorry nothing". My bet is that the compiler special cases C# keywords and preemptively doesn't generate C# for them. This means we bail out of our completion path entirely and return an empty completion list breaking the flow. That issue is tracked here: https://github.com/dotnet/aspnetcore/issues/37568 - Razor tooling wasn't directly responsible for the second issue; however, wes till needed to come up with a low-risk fix. The fix I landed on was to special case the bug and call it out specifically in code. The special case consists of three components: 1. Only check special cases if we failed to resolve a language. This is already a completion failure case so in the worst case we still don't provide completion 2. Detecting if we're in an `isIncomplete: true` scenario by looking at the trigger kind and seeing if it's `TriggerForIncompleteCompletions`next we look at the word span that's currently active 3. Detecting if the user is attempting to type a C# keyword (full match like `using` in `@using|`) - Given this fix is going to go through QB for dev17 I added insane amounts of tests/checks to ensure things are of the highest quality / we don't degrade functionality. ### Before  ### After  Fixes #5606
NTaylorMullen
referenced
this issue
Oct 15, 2021
- This is part 2/2 to fix `@using` statement completion in Razor files. Part 1 is over in the dotnet/roslyn repo: [PR](dotnet/roslyn#57160) - So the two components to this issue are as follows: 1. C# was throwing whenever they'd be in the process of returning `isIncomplete: true` completion lists and filter down to 0 items. This typically happened at the `n` of `@using`. Therefore things would explode preventing us from being able to control the completion experience 2. Found that the Razor compiler doesn't generate C# for `@using` statements. This means when we try to query what language exists at `@using|` it says "sorry nothing". My bet is that the compiler special cases C# keywords and preemptively doesn't generate C# for them. This means we bail out of our completion path entirely and return an empty completion list breaking the flow. That issue is tracked here: https://github.com/dotnet/aspnetcore/issues/37568 - Razor tooling wasn't directly responsible for the second issue; however, wes till needed to come up with a low-risk fix. The fix I landed on was to special case the bug and call it out specifically in code. The special case consists of three components: 1. Only check special cases if we failed to resolve a language. This is already a completion failure case so in the worst case we still don't provide completion 2. Detecting if we're in an `isIncomplete: true` scenario by looking at the trigger kind and seeing if it's `TriggerForIncompleteCompletions`next we look at the word span that's currently active 3. Detecting if the user is attempting to type a C# keyword (full match like `using` in `@using|`) - Given this fix is going to go through QB for dev17 I added insane amounts of tests/checks to ensure things are of the highest quality / we don't degrade functionality. ### Before  ### After  Fixes #5606
NTaylorMullen
referenced
this issue
Oct 15, 2021
- This is part 2/2 to fix `@using` statement completion in Razor files. Part 1 is over in the dotnet/roslyn repo: [PR](dotnet/roslyn#57160) - So the two components to this issue are as follows: 1. C# was throwing whenever they'd be in the process of returning `isIncomplete: true` completion lists and filter down to 0 items. This typically happened at the `n` of `@using`. Therefore things would explode preventing us from being able to control the completion experience 2. Found that the Razor compiler doesn't generate C# for `@using` statements. This means when we try to query what language exists at `@using|` it says "sorry nothing". My bet is that the compiler special cases C# keywords and preemptively doesn't generate C# for them. This means we bail out of our completion path entirely and return an empty completion list breaking the flow. That issue is tracked here: https://github.com/dotnet/aspnetcore/issues/37568 - Razor tooling wasn't directly responsible for the second issue; however, wes till needed to come up with a low-risk fix. The fix I landed on was to special case the bug and call it out specifically in code. The special case consists of three components: 1. Only check special cases if we failed to resolve a language. This is already a completion failure case so in the worst case we still don't provide completion 2. Detecting if we're in an `isIncomplete: true` scenario by looking at the trigger kind and seeing if it's `TriggerForIncompleteCompletions`next we look at the word span that's currently active 3. Detecting if the user is attempting to type a C# keyword (full match like `using` in `@using|`) - Given this fix is going to go through QB for dev17 I added insane amounts of tests/checks to ensure things are of the highest quality / we don't degrade functionality. ### Before  ### After  Fixes #5606
NTaylorMullen
referenced
this issue
Oct 18, 2021
- This is part 2/2 to fix `@using` statement completion in Razor files. Part 1 is over in the dotnet/roslyn repo: [PR](dotnet/roslyn#57160) - So the two components to this issue are as follows: 1. C# was throwing whenever they'd be in the process of returning `isIncomplete: true` completion lists and filter down to 0 items. This typically happened at the `n` of `@using`. Therefore things would explode preventing us from being able to control the completion experience 2. Found that the Razor compiler doesn't generate C# for `@using` statements. This means when we try to query what language exists at `@using|` it says "sorry nothing". My bet is that the compiler special cases C# keywords and preemptively doesn't generate C# for them. This means we bail out of our completion path entirely and return an empty completion list breaking the flow. That issue is tracked here: https://github.com/dotnet/aspnetcore/issues/37568 - Razor tooling wasn't directly responsible for the second issue; however, wes till needed to come up with a low-risk fix. The fix I landed on was to special case the bug and call it out specifically in code. The special case consists of three components: 1. Only check special cases if we failed to resolve a language. This is already a completion failure case so in the worst case we still don't provide completion 2. Detecting if we're in an `isIncomplete: true` scenario by looking at the trigger kind and seeing if it's `TriggerForIncompleteCompletions`next we look at the word span that's currently active 3. Detecting if the user is attempting to type a C# keyword (full match like `using` in `@using|`) - Given this fix is going to go through QB for dev17 I added insane amounts of tests/checks to ensure things are of the highest quality / we don't degrade functionality. ### Before  ### After  Fixes #5606
|
We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process. |
|
After typing “@using” in _Imports.razor file of the Blazor Server 6.0 project, The yellow bar pop up, For log files see here:
|
ghost
added
the
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Basically if we try and correlate C# mappings at
@using|there are no C# source mappings to operate on. Meaning, the compiler doesn't generate C# for partial using directives which results in broken tooling experiences like so:The text was updated successfully, but these errors were encountered: