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

Breakpoint set on a very different line #3902

Closed
vasily-kirichenko opened this issue Nov 7, 2017 · 5 comments
Closed

Breakpoint set on a very different line #3902

vasily-kirichenko opened this issue Nov 7, 2017 · 5 comments
Labels
Area-Debug stepping, debug points, stacks and more Bug Impact-Medium (Internal MS Team use only) Describes an issue with moderate impact on existing code.
Milestone

Comments

@vasily-kirichenko
Copy link
Contributor

I think it's a new level of breakpoints weirdness:

1

15.5 pre 3

@vasily-kirichenko
Copy link
Contributor Author

vasily-kirichenko commented Nov 7, 2017

Or try to debug shouldProvideCompletion function. Good luck :)

let shouldProvideCompletion (documentId: DocumentId, filePath: string, defines: string list, text: SourceText, position: int) : bool =
        let textLines = text.Lines
        let triggerLine = textLines.GetLineFromPosition position
        let colorizationData = Tokenizer.getColorizationData(documentId, text, triggerLine.Span, Some filePath, defines, CancellationToken.None)
        colorizationData.Count = 0 || // we should provide completion at the start of empty line, where there are no tokens at all
        colorizationData.Exists (fun classifiedSpan -> 
            classifiedSpan.TextSpan.IntersectsWith position &&
            (
                match classifiedSpan.ClassificationType with
                | ClassificationTypeNames.Comment
                | ClassificationTypeNames.StringLiteral
                | ClassificationTypeNames.ExcludedCode
                | ClassificationTypeNames.NumericLiteral
                | ClassificationTypeNames.VerbatimStringLiteral
                | ClassificationTypeNames.Text -> false
                | _ -> true // anything else is a valid classification type
            ))

There is absolutely no way to set a breakpoint so that colorizationData value can be inspected.

@cartermp cartermp added this to the VS 2017 Updates milestone Nov 7, 2017
@cartermp cartermp added Bug Impact-Medium (Internal MS Team use only) Describes an issue with moderate impact on existing code. labels Nov 7, 2017
@dsyme
Copy link
Contributor

dsyme commented Nov 8, 2017

Interesting, must be in our handling of a || b and a && b. We should at least be committing a breakpoint before the start of these constructs

@vasily-kirichenko
Copy link
Contributor Author

vasily-kirichenko commented Nov 8, 2017

It jumps to another method. This is something new.

@dsyme
Copy link
Contributor

dsyme commented Nov 8, 2017

@vasily-kirichenko Yes indeed

@cartermp cartermp modified the milestones: VS 2017 Updates, 16.0 Jun 20, 2018
@cartermp cartermp modified the milestones: 16.0, 16.1 Feb 21, 2019
@cartermp cartermp modified the milestones: 16.1, 16.2 Apr 23, 2019
@cartermp cartermp modified the milestones: 16.2, Backlog Apr 30, 2019
@dsyme dsyme added Area-Debug stepping, debug points, stacks and more and removed Area-LangService-API labels Aug 24, 2021
@dsyme
Copy link
Contributor

dsyme commented Aug 24, 2021

This is covered by #11980

@dsyme dsyme closed this as completed Aug 24, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Debug stepping, debug points, stacks and more Bug Impact-Medium (Internal MS Team use only) Describes an issue with moderate impact on existing code.
Projects
None yet
Development

No branches or pull requests

3 participants