This repository has been archived by the owner on Jan 2, 2021. It is now read-only.
Fix #237 #243
Merged
Fix #237 #243
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The bug was caused by broken transitivity of the comparison function used to sort spans. Nested spans were meant to be sorted in innermost-first order, with the first (innermost) one being used to get type information about the symbol at a given position. Because the comparison function considered any two non-nested spans to be EQ, the sort could incorrectly conclude (by transitivity) that two nested spans were equal, and thus leave them in incorrect relative order. This resulted in the innermost span sometimes not appearing at the front of the list of spans which enclose a given point, and hover reporting the type of a bigger expression in which the point appeared. The solution imposes ordering on non-nested spans by comparing their starting positions, thus fixing transitivity. Fixes #237 (... probably along with a bunch of other little bugs caused by the same mistake).
cocreature
approved these changes
Dec 14, 2019
pepeiborra
pushed a commit
to pepeiborra/ide
that referenced
this pull request
Dec 29, 2020
The bug was caused by broken transitivity of the comparison function used to sort spans. Nested spans were meant to be sorted in innermost-first order, with the first (innermost) one being used to get type information about the symbol at a given position. Because the comparison function considered any two non-nested spans to be EQ, the sort could incorrectly conclude (by transitivity) that two nested spans were equal, and thus leave them in incorrect relative order. This resulted in the innermost span sometimes not appearing at the front of the list of spans which enclose a given point, and hover reporting the type of a bigger expression in which the point appeared. The solution imposes ordering on non-nested spans by comparing their starting positions, thus fixing transitivity. Fixes haskell/ghcide#237 (... probably along with a bunch of other little bugs caused by the same mistake).
pepeiborra
pushed a commit
to pepeiborra/ide
that referenced
this pull request
Dec 29, 2020
The bug was caused by broken transitivity of the comparison function used to sort spans. Nested spans were meant to be sorted in innermost-first order, with the first (innermost) one being used to get type information about the symbol at a given position. Because the comparison function considered any two non-nested spans to be EQ, the sort could incorrectly conclude (by transitivity) that two nested spans were equal, and thus leave them in incorrect relative order. This resulted in the innermost span sometimes not appearing at the front of the list of spans which enclose a given point, and hover reporting the type of a bigger expression in which the point appeared. The solution imposes ordering on non-nested spans by comparing their starting positions, thus fixing transitivity. Fixes haskell/ghcide#237 (... probably along with a bunch of other little bugs caused by the same mistake).
pepeiborra
pushed a commit
to pepeiborra/ide
that referenced
this pull request
Dec 29, 2020
The bug was caused by broken transitivity of the comparison function used to sort spans. Nested spans were meant to be sorted in innermost-first order, with the first (innermost) one being used to get type information about the symbol at a given position. Because the comparison function considered any two non-nested spans to be EQ, the sort could incorrectly conclude (by transitivity) that two nested spans were equal, and thus leave them in incorrect relative order. This resulted in the innermost span sometimes not appearing at the front of the list of spans which enclose a given point, and hover reporting the type of a bigger expression in which the point appeared. The solution imposes ordering on non-nested spans by comparing their starting positions, thus fixing transitivity. Fixes haskell/ghcide#237 (... probably along with a bunch of other little bugs caused by the same mistake).
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The bug was caused by broken transitivity of the comparison function used to
sort spans. Nested spans were meant to be sorted in innermost-first order, with
the first (innermost) one being used to get type information about the symbol at
a given position.
Because the comparison function considered any two non-nested spans to be EQ,
the sort could incorrectly conclude (by transitivity) that two nested spans were
equal, and thus leave them in incorrect relative order. This resulted in the
innermost span sometimes not appearing at the front of the list of spans which
enclose a given point, and hover reporting the type of a bigger expression in
which the point appeared.
The solution imposes ordering on non-nested spans by comparing their starting
positions, thus fixing transitivity.
Fixes #237 (... probably along with a bunch of other little bugs caused by the
same mistake).