Skip to content
Snippets Groups Projects
Select Git revision
0 results
Search by author
  • Any Author
  • Joris Burgers Joris Burgers jorwas
  • Reinier Maas Reinier Maas trac-simplifierticks
  • Reinier Maas Reinier Maas ReinierMaas
  • Victor Cacciari Miraldo Victor Cacciari Miraldo VictorCMiraldo
4 authors
  1. Feb 05, 2024
  3. Feb 01, 2024
    • Andrei Borzenkov's avatar
      Namespacing for WARNING/DEPRECATED pragmas (#24396) · 151dda4e
      Andrei Borzenkov authored and Marge Bot's avatar Marge Bot committed 
      New syntax for WARNING and DEPRECATED pragmas was added,
namely namespace specifierss:

  namespace_spec ::= 'type' | 'data' | {- empty -}

  warning ::= warning_category namespace_spec namelist strings

  deprecation ::= namespace_spec namelist strings

A new data type was introduced to represent these namespace specifiers:

  data NamespaceSpecifier =
    NoSpecifier |
    TypeNamespaceSpecifier (EpToken "type") |
    DataNamespaceSpecifier (EpToken "data")

Extension field XWarning now contains this NamespaceSpecifier.

lookupBindGroupOcc function was changed: it now takes NamespaceSpecifier
and checks that the namespace of the found names matches the passed flag.
With this change {-# WARNING data D "..." #-} pragma will only affect value
namespace and {-# WARNING type D "..." #-} will only affect type
namespace. The same logic is applicable to DEPRECATED pragmas.

Finding duplicated warnings inside rnSrcWarnDecls now takes into
consideration NamespaceSpecifier flag to allow warnings with the
same names that refer to different namespaces.
      151dda4e
    • Teo Camarasu's avatar
      doc: Add -Dn flag to user guide · 94ce031d
      Teo Camarasu authored and Marge Bot's avatar Marge Bot committed 
      Resolves #24394
      94ce031d
  5. Jan 24, 2024
  7. Jan 20, 2024
  9. Jan 16, 2024
  11. Jan 15, 2024
    • Krzysztof Gogolewski's avatar
      Make the build more strict on documentation errors · da908790
      Krzysztof Gogolewski authored and Marge Bot's avatar Marge Bot committed 
      * Detect undefined labels. This can be tested by adding :ref:`nonexistent`
  to a documentation rst file; attempting to build docs will fail.
  Fixed the undefined label in `9.8.1-notes.rst`.
* Detect errors. While we have plenty of warnings, we can at least enforce
  that Sphinx does not report errors.
  Fixed the error in `required_type_arguments.rst`.

Unrelated change: I have documented that the `-dlint` enables
`-fcatch-nonexhaustive-cases`, as can be verified by checking
`enableDLint`.
      da908790
  13. Jan 13, 2024
  15. Jan 10, 2024
  17. Jan 08, 2024
  19. Jan 07, 2024
  21. Jan 01, 2024
  23. Dec 25, 2023
  25. Dec 24, 2023
  27. Dec 20, 2023
  29. Dec 15, 2023
  31. Dec 13, 2023
  33. Dec 11, 2023
    • Arnaud Spiwack's avatar
      Linear let and where bindings · 8e0446df
      Arnaud Spiwack authored 
      For expediency, the initial implementation of linear types in GHC
made it so that let and where binders would always be considered
unrestricted. This was rather unpleasant, and probably a big obstacle
to adoption. At any rate, this was not how the proposal was designed.

This patch fixes this infelicity. It was surprisingly difficult to
build, which explains, in part, why it took so long to materialise.

As of this patch, let or where bindings marked with %1 will be
linear (respectively %p for an arbitrary multiplicity p). Unmarked let
will infer their multiplicity.

Here is a prototypical example of program that used to be rejected and
is accepted with this patch:

```haskell
f :: A %1 -> B
g :: B %1 -> C

h :: A %1 -> C
h x = g y
  where
    y = f x
```

Exceptions:
- Recursive let are unrestricted, as there isn't a clear semantics of
  what a linear recursive binding would be.
- Destructive lets with lazy bindings are unrestricted, as their
  desugaring isn't linear (see also #23461).
- (Strict) destructive lets with inferred polymorphic type are
  unrestricted. Because the desugaring isn't linear (See #18461
  down-thread).

Closes #18461 and #18739

Co-authored-by: @jackohughes
      8e0446df
    • Vladislav Zavialov's avatar
      Make forall a keyword (#23719) · d9e4c597
      Vladislav Zavialov authored and Marge Bot's avatar Marge Bot committed 
      Before this change, GHC used to accept `forall` as a term-level
identifier:

	-- from constraints-0.13
	forall :: forall p. (forall a. Dict (p a)) -> Dict (Forall p)
	forall d = ...

Now it is a parse error.

The -Wforall-identifier warning has served its purpose and is now
a deprecated no-op.
      d9e4c597
  35. Nov 26, 2023
  37. Nov 21, 2023
  39. Nov 17, 2023
  41. Nov 16, 2023
  43. Nov 15, 2023
  45. Nov 09, 2023
  47. Nov 03, 2023
    • Vladislav Zavialov's avatar
      T2T in Expressions (#23738) · 0dfb1fa7
      Vladislav Zavialov authored and Marge Bot's avatar Marge Bot committed 
      This patch implements the T2T (term-to-type) transformation in
expressions. Given a function with a required type argument
	vfun :: forall a -> ...

the user can now call it as
	vfun (Maybe Int)

instead of
	vfun (type (Maybe Int))

The Maybe Int argument is parsed and renamed as a term (HsExpr), but then
undergoes a conversion to a type (HsType).
See the new function expr_to_type in compiler/GHC/Tc/Gen/App.hs
and Note [RequiredTypeArguments and the T2T mapping]

Left as future work: checking for puns.
      0dfb1fa7
    • Jaro Reinders's avatar
      Add NCG support for common 64bit operations to the x86 backend. · 6755d833
      Jaro Reinders authored and Andreas Klebinger's avatar Andreas Klebinger committed 
      These used to be implemented via C calls which was obviously quite bad
for performance for operations like simple addition.

Co-authored-by: Andreas Klebinger
      6755d833
  49. Nov 01, 2023
    • Ryan Scott's avatar
      More robust checking for DataKinds · 9f9c9227
      Ryan Scott authored and Marge Bot's avatar Marge Bot committed 
      As observed in #22141, GHC was not doing its due diligence in catching code
that should require `DataKinds` in order to use. Most notably, it was allowing
the use of arbitrary data types in kind contexts without `DataKinds`, e.g.,

```hs
data Vector :: Nat -> Type -> Type where
```

This patch revamps how GHC tracks `DataKinds`. The full specification is
written out in the `DataKinds` section of the GHC User's Guide, and the
implementation thereof is described in `Note [Checking for DataKinds]` in
`GHC.Tc.Validity`. In brief:

* We catch _type_-level `DataKinds` violations in the renamer. See
  `checkDataKinds` in `GHC.Rename.HsType` and `check_data_kinds` in
  `GHC.Rename.Pat`.

* We catch _kind_-level `DataKinds` violations in the typechecker, as this
  allows us to catch things that appear beneath type synonyms. (We do *not*
  want to do this in type-level contexts, as it is perfectly fine for a type
  synonym to mention something that requires DataKinds while still using the
  type synonym in a module that doesn't enable DataKinds.) See `checkValidType`
  in `GHC.Tc.Validity`.

* There is now a single `TcRnDataKindsError` that classifies all manner of
  `DataKinds` violations, both in the renamer and the typechecker. The
  `NoDataKindsDC` error has been removed, as it has been subsumed by
  `TcRnDataKindsError`.

* I have added `CONSTRAINT` is `isKindTyCon`, which is what checks for illicit
  uses of data types at the kind level without `DataKinds`. Previously,
  `isKindTyCon` checked for `Constraint` but not `CONSTRAINT`. This is
  inconsistent, given that both `Type` and `TYPE` were checked by `isKindTyCon`.
  Moreover, it thwarted the implementation of the `DataKinds` check in
  `checkValidType`, since we would expand `Constraint` (which was OK without
  `DataKinds`) to `CONSTRAINT` (which was _not_ OK without `DataKinds`) and
  reject it. Now both are allowed.

* I have added a flurry of additional test cases that test various corners of
  `DataKinds` checking.

Fixes #22141.
      9f9c9227
    • Krzysztof Gogolewski's avatar
      docs: fix ScopedTypeVariables example (#24101) · 7a90020f
      Krzysztof Gogolewski authored and Marge Bot's avatar Marge Bot committed 
      The previous example didn't compile.

Furthermore, it wasn't demonstrating the point properly.
I have changed it to an example which shows that 'a' in the signature
must be the same 'a' as in the instance head.
      7a90020f
  51. Oct 24, 2023
  53. Oct 23, 2023
  55. Oct 22, 2023
    • Cheng Shao's avatar
      rts: drop stale mentions of MIN_UPD_SIZE · c1e3719c
      Cheng Shao authored and Marge Bot's avatar Marge Bot committed 
      We used to have MIN_UPD_SIZE macro that describes the minimum reserved
size for thunks, so that the thunk can be overwritten in place as
indirections or blackholes. However, this macro has not been actually
defined or used anywhere since a long time ago; StgThunkHeader already
reserves a padding word for this purpose. Hence this patch which drops
stale mentions of MIN_UPD_SIZE.
      c1e3719c
    • John Ericson's avatar
      Get rid of all mention of `mk/config.h` · 7dfcab2f
      John Ericson authored and Marge Bot's avatar Marge Bot committed 
      The RTS configure script is now solely responsible for managing its
headers; the top level configure script does not help.
      7dfcab2f
  57. Oct 14, 2023
  59. Oct 10, 2023