Don't put breakpoints on component start tags, end tags or attributes#12422
Don't put breakpoints on component start tags, end tags or attributes#12422davidwengier merged 1 commit intodotnet:mainfrom
Conversation
| while (sourceText.GetLinePosition(hostDocumentIndex).Line == hostDocumentPosition.Line) | ||
| { | ||
| return false; | ||
| if (_documentMappingService.TryMapToCSharpPositionOrNext(csharpDocument, hostDocumentIndex, out _, out projectedIndex)) |
There was a problem hiding this comment.
There was a problem hiding this comment.
Ahh, turns out we've discussed this before: #9291
TL;DR, source mappings are ordered by the GeneratedSpan (as the compiler adds source mappings as it writes the generated file, not necessarily as it reads the Razor file) so an early exit there would potentially miss something.
There was a problem hiding this comment.
OK, that makes sense. But now I'm confused how that code knows it's the "next" one if there are multiple C# ranges on the same line? The "next" code short circuits based on a mapping being on the line, not that it is the first one on that line after the span.
There was a problem hiding this comment.
Yeah, I suspect it doesn't, and is entirely possible to break. I would guess in "normal" Razor code the code-gen is generally in order of the original span, an it's only certain constructs that break it, so maybe we've just been lucky and nobody has hit it.
Having said that, I did get one test failure when I added to early break, I just didn't dig in. It was a document highlight test though, which is somewhat intriguing.
2 participants
Fixes #12421
Fall out from mapping component tags