Add SynType.Paren

[auduchinok]

Keeps parser knowledge about (possibly nested) parens found when parsing syntax types. It's needed when trying to get tree structures in cases like the following:

type A = int * (int * int)
type B = (int -> int) -> int
type C = ((int))

I'll add tests when existing ones are green.

[TIHan]

This seems fair, but Paren really isn't a "Type" and has no significance in the TypeChecker, which is why you simply skip over it. Should we add another union case in the syntax that is strictly for information purposes, namely for tooling?

I know we do not keep token information around, which is the problem. We don't have a mechanism to extract that information. If we were able to build something that would allow someone to query for tokens based on a range, would that be useful and potentially help solve your issue?

[dsyme]

This seems fair, but Paren really isn't a "Type" and has no significance in the TypeChecker, which is why you simply skip over it. Should we add another union case in the syntax that is strictly for information purposes, namely for tooling?

Yes, we should do this - the SyntaxTree type is slowly evolving to include all necessary syntax trivia (it should have always been like this, my fault way back at the start )

[auduchinok]

This seems fair, but Paren really isn't a "Type" and has no significance in the TypeChecker, which is why you simply skip over it.

I guess nor SynExpr.Paren is really an expression in that sense, or SynPat.Paren is a pattern. 🙂

Should we add another union case in the syntax that is strictly for information purposes, namely for tooling?

I think it's fine, since SynType is a syntax construct that various things, including the type checker, use and it seems fair to preserve more syntax info if it's needed for tooling the same way it was already done in other places in the SyntaxTree types.
It also makes it more similar to SynPat and SynExpr where a special case is added to preserve the parens info.

If we were able to build something that would allow someone to query for tokens based on a range, would that be useful and potentially help solve your issue?

We're mostly interested in the correct file structure w.r.t. ranges here, not the particular tokens info, so it'd probably not make it easier in our use case.

[dsyme]

I know we do not keep token information around, which is the problem. We don't have a mechanism to extract that information. If we were able to build something that would allow someone to query for tokens based on a range, would that be useful and potentially help solve your issue?

Note I believe Fantomas has a phase that folds the token stream back into an extra-augmented version of the SyntaxTree, prior to source code formatting.

However if the tooling built in this repo needs extra syntax information, we should just add it.

[TIHan]

the SyntaxTree type is slowly evolving to include all necessary syntax trivia (it should have always been like this, my fault way back at the start )

There is no fault, it just is what it is. In a perfect world, I'm wondering how we would model the trivia; because I don't know.

I guess nor SynExpr.Paren is really an expression in that sense, or SynPat.Paren is a pattern.

SynExpr.Paren does seem to have a bit more significance for the TypeChecker. But, SynPat.Paren does not.

It also makes it more similar to SynPat and SynExpr where a special case is added to preserve the parens info.

This makes sense; we already seem to do this in other places.

We're mostly interested in the correct file structure

Makes sense as well.

Sorry for being nit-picky. Whenever I see new cases added in the syntax tree, I always want to discuss it and make sure. I feel much better about SynType.Paren now :). Thank you all for explaining.

[TIHan]

Marking approved, pending tests and minor nit.

[KevinRansom]

@auduchinok ,

there is a test failure

System.Exception : neg04.err neg04.bsl differ; "diff between [D:\a\1\s\tests\fsharp\typecheck\sigs\neg04.bsl] and [D:\a\1\s\tests\fsharp\typecheck\sigs\neg04.err]

line 113

neg04.fs(144,10,144,25): typecheck error FS0193: Type constraint mismatch. The type
neg04.fs(144,10,144,26): typecheck error FS0193: Type constraint mismatch. The type

diff between [D:\a\1\s\tests\fsharp\typecheck\sigs\neg04.bsl] and [D:\a\1\s\tests\fsharp\typecheck\sigs\neg04.err]

line 125
neg04.fs(150,10,150,26): typecheck error FS0193: Type constraint mismatch. The type
neg04.fs(150,10,150,27): typecheck error FS0193: Type constraint mismatch. The type

"; neg04.vserr neg04.bsl differ; "diff between [D:\a\1\s\tests\fsharp\typecheck\sigs\neg04.bsl] and [D:\a\1\s\tests\fsharp\typecheck\sigs\neg04.vserr]

line 113
neg04.fs(144,10,144,25): typecheck error FS0193: Type constraint mismatch. The type
neg04.fs(144,10,144,26): typecheck error FS0193: Type constraint mismatch. The type

diff between [D:\a\1\s\tests\fsharp\typecheck\sigs\neg04.bsl] and [D:\a\1\s\tests\fsharp\typecheck\sigs\neg04.vserr]

line 125
neg04.fs(150,10,150,26): typecheck error FS0193: Type constraint mismatch. The type
neg04.fs(150,10,150,27): typecheck error FS0193: Type constraint mismatch. The type

"````

[KevinRansom]

@auduchinok , I think your code is correct, and the test baseline needs updating, I'm taking care of it.

[auduchinok]

@KevinRansom Thanks, but please don't merge it yet, I'll need to add a test case before it goes in.

[KevinRansom]

K. I'll WIP it.

[auduchinok]

It's ready.

@KevinRansom Thank you for the baselines updates!