Inlay hints/PatternTypeHintsStage: support match clause #756
Conversation
DedSec256
commented
Oct 31, 2024
•
DedSec256
commented
- FCS update
|
@DedSec256 Do you think it could make sense to introduce another option, so hints for bindings/parameter declarations could be controlled separately? With both currently defaulting to 'push-to-hint' it doesn't make much difference, but I'm also trying to imagine if somebody could want to make the declaration hints be always shown while keep the 'match' ones in push-to-hint mode. |
DedSec256
force-pushed
the
ber.a/matchClausePatterns
branch
from
3297ca0 to
5ce6bfb
Compare
| @@ -41,34 +41,34 @@ let g||(15) = fun x -> () | |||
|
|
|||
| type A(x||(16)) = | |||
| do | |||
| let x||(17) = 3 | |||
There was a problem hiding this comment.
Accidentally fixed the case when hints showed for some local bindings even if it was disabled
|
Perhaps, we can name it
|
"Clause" sounds like a rather technical term to me. I've never heard it from non-compiler people. Something like "patterns" or "branches" may sound much more user-friendly here, I think? |
| @@ -130,6 +130,21 @@ let (|String|) (x: MyStruct) : string = String(x.myString) | |||
|
|
|||
| let f1 (x & Int(i) & String(s)) = () | |||
|
|
|||
|
|
|||
| let _ = function x -> () | |||
There was a problem hiding this comment.
What do you think about splitting this test files into smaller ones, so it could be easier to think about unrelated cases separately?
ReSharper.FSharp/test/data/features/daemon/typeHints/Signatures - Locals 01.fs.gold
Outdated
Show resolved
Hide resolved
| member _.Dispose(): unit = () | ||
|
|
||
| let delimiter (delim1, delim2, value) = | ||
| { new IFormattable with |
There was a problem hiding this comment.
Is it really a part of match-related test?
If the idea here is to test how different settings work, can these tests be simplified to only include minimal code needed for such tests?
There was a problem hiding this comment.
I'd like to suggest we refactor these tests in a separate pull request.
There was a problem hiding this comment.
Yes, sounds good. Maybe we should merge the refactor first then.
DedSec256
force-pushed
the
ber.a/matchClausePatterns
branch
from
21e091f to
38d2c7e
Compare
DedSec256
force-pushed
the
ber.a/matchClausePatterns
branch
from
38d2c7e to
c476a56
Compare
| [<SettingsEntry(PushToHintMode.PushToShowHints, | ||
| DescriptionResourceType = typeof<Strings>, | ||
| DescriptionResourceName = nameof(Strings.FSharpTypeHints_MatchPatterns_Description))>] | ||
| mutable ShowTypeHintsForMatchPatterns: PushToHintMode } |
There was a problem hiding this comment.
What's the idea behind having separate settings for patterns in local bindings and match clauses?
| let consumer = { TopLevelNodes = VisibilityConsumer(visibleRange, _.GetNavigationRange()) | ||
| LocalNodes = VisibilityConsumer(visibleRange, _.GetNavigationRange()) } | ||
| let consumer = { | ||
| TopLevelNodes = VisibilityConsumer(visibleRange, _.GetNavigationRange()) |
| @@ -181,7 +196,25 @@ type private PatternsHighlightingProcess(fsFile, settingsStore: IContextBoundSet | |||
| createTypeHintHighlighting fcsType defaultDisplayContext range pushToHintMode actionsProvider false | |||
| |> ValueSome | |||
|
|
|||
| | _ -> ValueNone | |||
| | :? IParametersOwnerPat as pattern -> | |||
| let y||(27) = 5 in () | ||
|
|
||
| match [[5]] with | ||
| | [[]||(28)]||(29) -> () |
There was a problem hiding this comment.
Do you think it makes sense to do it recursively here?
| | x :: _||(14) -> () | ||
| | _ :: x :: _||(15) -> () | ||
| | x :: _ :: _||(16) -> () | ||
| | x :: Some y||(17) :: _||(18) -> () |
There was a problem hiding this comment.
Do you think it makes sense to do it recursively here?
| do | ||
| let x||(12) = 3 | ||
| let x||(16) = 3 |
There was a problem hiding this comment.
@DedSec256 This seems unrelated to match clauses. Could you split these test cases, please?
