[Git][ghc/ghc][wip/T18723] 9 commits: Implement -Woperator-whitespace (#18834)

Wed Oct 21 09:39:17 UTC 2020

Ryan Scott pushed to branch wip/T18723 at Glasgow Haskell Compiler / GHC

Commits:
b5b3e34e by Vladislav Zavialov at 2020-10-19T18:16:20-04:00
Implement -Woperator-whitespace (#18834)

This patch implements two related warnings:

  -Woperator-whitespace-ext-conflict
      warns on uses of infix operators that would be parsed
      differently were a particular GHC extension enabled

  -Woperator-whitespace
      warns on prefix, suffix, and tight infix uses of infix
      operators

Updates submodules: haddock, containers.

- - - - -
9648d680 by Sylvain Henry at 2020-10-19T18:16:58-04:00
Remove pdocPrec

pdocPrec was only used in GHC.Cmm.DebugBlock.pprUnwindExpr, so remove
it. OutputableP becomes a one-function class which might be better for
performance.

- - - - -
ee5dcdf9 by Ben Gamari at 2020-10-20T00:47:54-04:00
testsuite: Add test for #18346

This was fixed by 4291bddaea3148908c55f235ee8978e1d9aa6f20.

- - - - -
6c7a5c0c by Krzysztof Gogolewski at 2020-10-20T00:48:29-04:00
Minor comments, update linear types docs

- Update comments: placeHolderTypeTc no longer exists
  "another level check problem" was a temporary comment from linear types
- Use Mult type synonym (reported in #18676)
- Mention multiplicity-polymorphic fields in linear types docs

- - - - -
58a1ca38 by nineonine at 2020-10-20T00:49:07-04:00
Compile modules with `-fobject-code` enabled to byte-code when loaded with `*` prefix in ghci (#8042)

The documentation states that when using :add and :load, the `*` prefix forces a module
to be loaded as byte-code. However, this seems to be ignored when -fobject-code has been
enabled. In that case, the compiled code is always used, regardless of whether the *-form
is used.

The idea is to consult the Targets in HscEnv and check the 'targetAllowObjCode' flag. If
the flag for given module is set, then patch up DynFlags and select compilation backend
accordingly.

This would require a linear scan of course, but that shouldn't be too costly.

- - - - -
59b08a5d by Ben Gamari at 2020-10-20T00:49:41-04:00
gitlab-ci: Rename FLAVOUR -> BUILD_FLAVOUR

Previously the Hadrian jobs used the `FLAVOUR` environment variable to
communicate which flavour `ci.sh` should build whereas `make` used
`BUILD_FLAVOUR`. This caused unnecessary confusion. Consolidate these
two.

- - - - -
ea736839 by Alan Zimmerman at 2020-10-20T08:35:34+01:00
API Annotations: Keep track of unicode for linear arrow notation

The linear arrow can be parsed as `%1 ->` or a direct single token unicode
equivalent.

Make sure that this distinction is captured in the parsed AST by using
IsUnicodeSyntax where it appears, and introduce a new API Annotation,
AnnMult to represent its location when unicode is not used.

Updated haddock submodule

- - - - -
cf3c3bcd by Ben Gamari at 2020-10-20T22:56:31-04:00
testsuite: Mark T12971 as fragile on Windows

Due to #17945.

- - - - -
d54abe25 by Ryan Scott at 2020-10-21T05:37:57-04:00
Check for large tuples more thoroughly

This fixes #18723 by:

* Moving the existing `GHC.Tc.Gen.HsType.bigConstraintTuple` validity
  check to `GHC.Rename.Utils.checkCTupSize` for consistency with
  `GHC.Rename.Utils.checkTupSize`, and
* Using `check(C)TupSize` when checking tuple _types_, in addition
  to checking names, expressions, and patterns.

Note that I put as many of these checks as possible in the typechecker so
that GHC can properly distinguish between boxed and constraint tuples. The
exception to this rule is checking names, which I perform in the renamer
(in `GHC.Rename.Env`) so that we can rule out `(,, ... ,,)` and
`''(,, ... ,,)` alike in one fell swoop.

While I was in town, I also removed the `HsConstraintTuple` and
`HsBoxedTuple` constructors of `HsTupleSort`, which are functionally
unused. This requires a `haddock` submodule bump.

- - - - -

30 changed files:

- .gitlab-ci.yml
- .gitlab/ci.sh
- compiler/GHC/Builtin/Types/Prim.hs
- compiler/GHC/Cmm/CallConv.hs
- compiler/GHC/Cmm/DebugBlock.hs
- compiler/GHC/CmmToLlvm/Regs.hs
- compiler/GHC/Core/Type.hs
- compiler/GHC/Driver/Flags.hs
- compiler/GHC/Driver/Pipeline.hs
- compiler/GHC/Driver/Session.hs
- compiler/GHC/Driver/Types.hs
- compiler/GHC/Hs/Type.hs
- compiler/GHC/Hs/Utils.hs
- compiler/GHC/Parser.y
- compiler/GHC/Parser/Annotation.hs
- compiler/GHC/Parser/Errors.hs
- compiler/GHC/Parser/Errors/Ppr.hs
- compiler/GHC/Parser/Lexer.x
- compiler/GHC/Parser/PostProcess.hs
- compiler/GHC/Parser/PostProcess/Haddock.hs
- compiler/GHC/Rename/Expr.hs
- compiler/GHC/Rename/HsType.hs
- compiler/GHC/Rename/Pat.hs
- compiler/GHC/Rename/Utils.hs
- compiler/GHC/Runtime/Eval.hs
- compiler/GHC/Tc/Gen/Expr.hs
- compiler/GHC/Tc/Gen/HsType.hs
- compiler/GHC/Tc/Gen/Pat.hs
- compiler/GHC/Tc/Module.hs
- compiler/GHC/Tc/TyCl.hs

The diff was not included because it is too large.

View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/82902c87c373e8a5cf1b15028e808cfe1537ced3...d54abe257241a73a86c39cff98ad39ef339f3714

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/82902c87c373e8a5cf1b15028e808cfe1537ced3...d54abe257241a73a86c39cff98ad39ef339f3714
You're receiving this email because of your account on gitlab.haskell.org.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-commits/attachments/20201021/aafe92e8/attachment.html>