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

Brittany introduces space in TypeApplications with ticked-constructor #370

Open
pbrisbin opened this issue Apr 12, 2022 · 0 comments · May be fixed by #376
Open

Brittany introduces space in TypeApplications with ticked-constructor #370

pbrisbin opened this issue Apr 12, 2022 · 0 comments · May be fixed by #376

Comments

@pbrisbin
Copy link

Brittany introduces an extra space in @'Bar, making it @ 'Bar. It handles @Bar correctly.

This has been happening for a number of versions, but it seems GHC 8.10 has been accepting it as still a TypeApplication. GHC 9.0 (more reasonably, IMO) sees it as trying to use a function named (@), which fails as out of scope.

% cat ~/brittany-repro.hs
main = do
    foo @'Bar baz
    foo @Bar baz
% stack exec brittany < ~/brittany-repro.hs
main = do
  foo @ 'Bar baz
  foo @Bar baz
% stack exec brittany -- --version
brittany version 0.14.0.2
Copyright (C) 2016-2019 Lennart Spitzner
Copyright (C) 2019 PRODA LTD
There is NO WARRANTY, to the extent permitted by law.
brittany.yaml
---
conf_debug:
  dconf_roundtrip_exactprint_only: false
  dconf_dump_bridoc_simpl_par: false
  dconf_dump_ast_unknown: false
  dconf_dump_bridoc_simpl_floating: false
  dconf_dump_config: false
  dconf_dump_bridoc_raw: false
  dconf_dump_bridoc_final: false
  dconf_dump_bridoc_simpl_alt: false
  dconf_dump_bridoc_simpl_indent: false
  dconf_dump_annotations: false
  dconf_dump_bridoc_simpl_columns: false
  dconf_dump_ast_full: false
conf_forward:
  options_ghc:
    - -XBangPatterns
    - -XDataKinds
    - -XDeriveAnyClass
    - -XDeriveFoldable
    - -XDeriveFunctor
    - -XDeriveGeneric
    - -XDeriveLift
    - -XDeriveTraversable
    - -XDerivingStrategies
    - -XFlexibleContexts
    - -XFlexibleInstances
    - -XGADTs
    - -XGeneralizedNewtypeDeriving
    - -XLambdaCase
    - -XMultiParamTypeClasses
    - -XNoImplicitPrelude
    - -XNoMonomorphismRestriction
    - -XOverloadedStrings
    - -XQuasiQuotes
    - -XRankNTypes
    - -XRecordWildCards
    - -XScopedTypeVariables
    - -XStandaloneDeriving
    - -XTypeApplications
    - -XTypeFamilies
conf_errorHandling:
  econf_ExactPrintFallback: ExactPrintFallbackModeInline
  econf_Werror: false
  econf_omit_output_valid_check: false
  econf_produceOutputOnErrors: false
conf_preprocessor:
  ppconf_CPPMode: CPPModeAbort
  ppconf_hackAroundIncludes: false
conf_obfuscate: false
conf_roundtrip_exactprint_only: false
conf_version: 1
conf_layout:
  lconfig_reformatModulePreamble: true
  lconfig_altChooser:
    tag: AltChooserBoundedSearch
    contents: 3
  lconfig_allowSingleLineExportList: false
  lconfig_importColumn: 60
  lconfig_hangingTypeSignature: false
  lconfig_importAsColumn: 50
  lconfig_alignmentLimit: 1
  lconfig_indentListSpecial: true
  lconfig_indentAmount: 2
  lconfig_alignmentBreakOnMultiline: true
  lconfig_cols: 80
  lconfig_indentPolicy: IndentPolicyLeft
  lconfig_indentWhereSpecial: true
  lconfig_columnAlignMode:
    tag: ColumnAlignModeDisabled
    contents: 0.7
ChickenProp added a commit to ChickenProp/brittany that referenced this issue Nov 1, 2022
Closes lspitzner#370.

Up to GHC 8.10,

    foo @ 'Bar

was a valid type application. In GHC 9 it's not, which means brittany
needs to allow

    foo @'Bar

which it now does.

The reason the space was needed was to allow a promoted type variable at
the head of a type-level list. That is,

    '['Foo]

is invalid syntax, because it initially parses as the character `'['`.
So the promoted type variable was always given a separator at the
beginning, and we'd get

    '[ 'Foo]

which was valid. Now we handle this case by specifically examining the
head of a type-level list; if it's promoted we introduce spaces, so

    '[ 'Foo ]
    '[Foo]

I've added tests for this and some related cases. In doing so I noticed
that unnecessary spaces get added in front of commas in these lists; I
believe that's a separate bug, and I've written a comment explaining why
it happens, but I haven't tried to fix it.

I'm not sure when the first alternates in the `FirstLastSingleton`
and `FirstLast` branches would ever be hit, so I'm not entirely sure if
the separators are necessary there. But since `docSeparator` disappears
at the end of a line and merges with adjacent separators, they should be
harmless.
ChickenProp added a commit to ChickenProp/brittany that referenced this issue Nov 1, 2022
Closes lspitzner#370.

Up to GHC 8.10,

    foo @ 'Bar

was a valid type application. In GHC 9 it's not, which means brittany
needs to allow

    foo @'Bar

which it now does.

The reason the space was needed was to allow a promoted type variable at
the head of a type-level list. That is,

    '['Foo]

is invalid syntax, because it initially parses as the character `'['`.
So the promoted type variable was always given a separator at the
beginning, and we'd get

    '[ 'Foo]

which was valid. Now we handle this case by specifically examining the
head of a type-level list; if it's promoted we introduce spaces, so

    '[ 'Foo ]
    '[Foo]

I've added tests for this and some related cases. In doing so I noticed
that unnecessary spaces get added in front of commas in these lists; I
believe that's a separate bug, and I've written a comment explaining why
it happens, but I haven't tried to fix it.

I'm not sure when the first alternates in the `FirstLastSingleton`
and `FirstLast` branches would ever be hit, so I'm not entirely sure if
the separators are necessary there. But since `docSeparator` disappears
at the end of a line and merges with adjacent separators, they should be
harmless.
@ChickenProp ChickenProp linked a pull request Nov 1, 2022 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants