| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Also add tests for the issue and -Winferred-safe-imports in general
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add JS backend adapted from the GHCJS project by Luite Stegeman.
Some features haven't been ported or implemented yet. Tests for these
features have been disabled with an associated gitlab ticket.
Bump array submodule
Work funded by IOG.
Co-authored-by: Jeffrey Young <jeffrey.young@iohk.io>
Co-authored-by: Luite Stegeman <stegeman@gmail.com>
Co-authored-by: Josh Meredith <joshmeredith2008@gmail.com>
|
| |
|
|
|
|
|
|
| |
The testsuite output now contains diagnostic codes, so many tests need
to be updated at once.
We decided it was best to keep the diagnostic codes in the testsuite
output, so that contributors don't inadvertently make changes to the
diagnostic codes.
|
| |
|
|
|
|
|
| |
This patch improves the uniformity of error message formatting by
printing constraints in quotes, as we do for types.
Fix #21167
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With this change, `Backend` becomes an abstract type
(there are no more exposed value constructors).
Decisions that were formerly made by asking "is the
current back end equal to (or different from) this named value
constructor?" are now made by interrogating the back end about
its properties, which are functions exported by `GHC.Driver.Backend`.
There is a description of how to migrate code using `Backend` in the
user guide.
Clients using the GHC API can find a backdoor to access the Backend
datatype in GHC.Driver.Backend.Internal.
Bumps haddock submodule.
Fixes #20927
|
| |
|
|
|
|
|
| |
This module exports unsafe pointer equality operations,
so we accordingly mark it as Unsafe.
Fixes #21433
|
| |
|
|
|
|
|
|
| |
This change makes it clear that it's the definition rather than any
usage which is a problem, and that rules defined in other modules will
still be used to do rewrites.
Fixes #20923
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Multiple home units allows you to load different packages which may depend on
each other into one GHC session. This will allow both GHCi and HLS to support
multi component projects more naturally.
Public Interface
~~~~~~~~~~~~~~~~
In order to specify multiple units, the -unit @⟨filename⟩ flag
is given multiple times with a response file containing the arguments for each unit.
The response file contains a newline separated list of arguments.
```
ghc -unit @unitLibCore -unit @unitLib
```
where the `unitLibCore` response file contains the normal arguments that cabal would pass to `--make` mode.
```
-this-unit-id lib-core-0.1.0.0
-i
-isrc
LibCore.Utils
LibCore.Types
```
The response file for lib, can specify a dependency on lib-core, so then modules in lib can use modules from lib-core.
```
-this-unit-id lib-0.1.0.0
-package-id lib-core-0.1.0.0
-i
-isrc
Lib.Parse
Lib.Render
```
Then when the compiler starts in --make mode it will compile both units lib and lib-core.
There is also very basic support for multiple home units in GHCi, at the
moment you can start a GHCi session with multiple units but only the
:reload is supported. Most commands in GHCi assume a single home unit,
and so it is additional work to work out how to modify the interface to
support multiple loaded home units.
Options used when working with Multiple Home Units
There are a few extra flags which have been introduced specifically for
working with multiple home units. The flags allow a home unit to pretend
it’s more like an installed package, for example, specifying the package
name, module visibility and reexported modules.
-working-dir ⟨dir⟩
It is common to assume that a package is compiled in the directory
where its cabal file resides. Thus, all paths used in the compiler
are assumed to be relative to this directory. When there are
multiple home units the compiler is often not operating in the
standard directory and instead where the cabal.project file is
located. In this case the -working-dir option can be passed which
specifies the path from the current directory to the directory the
unit assumes to be it’s root, normally the directory which contains
the cabal file.
When the flag is passed, any relative paths used by the compiler are
offset by the working directory. Notably this includes -i and
-I⟨dir⟩ flags.
-this-package-name ⟨name⟩
This flag papers over the awkward interaction of the PackageImports
and multiple home units. When using PackageImports you can specify
the name of the package in an import to disambiguate between modules
which appear in multiple packages with the same name.
This flag allows a home unit to be given a package name so that you
can also disambiguate between multiple home units which provide
modules with the same name.
-hidden-module ⟨module name⟩
This flag can be supplied multiple times in order to specify which
modules in a home unit should not be visible outside of the unit it
belongs to.
The main use of this flag is to be able to recreate the difference
between an exposed and hidden module for installed packages.
-reexported-module ⟨module name⟩
This flag can be supplied multiple times in order to specify which
modules are not defined in a unit but should be reexported. The
effect is that other units will see this module as if it was defined
in this unit.
The use of this flag is to be able to replicate the reexported
modules feature of packages with multiple home units.
Offsetting Paths in Template Haskell splices
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
When using Template Haskell to embed files into your program,
traditionally the paths have been interpreted relative to the directory
where the .cabal file resides. This causes problems for multiple home
units as we are compiling many different libraries at once which have
.cabal files in different directories.
For this purpose we have introduced a way to query the value of the
-working-dir flag to the Template Haskell API. By using this function we
can implement a makeRelativeToProject function which offsets a path
which is relative to the original project root by the value of
-working-dir.
```
import Language.Haskell.TH.Syntax ( makeRelativeToProject )
foo = $(makeRelativeToProject "./relative/path" >>= embedFile)
```
> If you write a relative path in a Template Haskell splice you should use the makeRelativeToProject function so that your library works correctly with multiple home units.
A similar function already exists in the file-embed library. The
function in template-haskell implements this function in a more robust
manner by honouring the -working-dir flag rather than searching the file
system.
Closure Property for Home Units
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For tools or libraries using the API there is one very important closure
property which must be adhered to:
> Any dependency which is not a home unit must not (transitively) depend
on a home unit.
For example, if you have three packages p, q and r, then if p depends on
q which depends on r then it is illegal to load both p and r as home
units but not q, because q is a dependency of the home unit p which
depends on another home unit r.
If you are using GHC by the command line then this property is checked,
but if you are using the API then you need to check this property
yourself. If you get it wrong you will probably get some very confusing
errors about overlapping instances.
Limitations of Multiple Home Units
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
There are a few limitations of the initial implementation which will be smoothed out on user demand.
* Package thinning/renaming syntax is not supported
* More complicated reexports/renaming are not yet supported.
* It’s more common to run into existing linker bugs when loading a
large number of packages in a session (for example #20674, #20689)
* Backpack is not yet supported when using multiple home units.
* Dependency chasing can be quite slow with a large number of
modules and packages.
* Loading wired-in packages as home units is currently not supported
(this only really affects GHC developers attempting to load
template-haskell).
* Barely any normal GHCi features are supported, it would be good to
support enough for ghcid to work correctly.
Despite these limitations, the implementation works already for nearly
all packages. It has been testing on large dependency closures,
including the whole of head.hackage which is a total of 4784 modules
from 452 packages.
Internal Changes
~~~~~~~~~~~~~~~~
* The biggest change is that the HomePackageTable is replaced with the
HomeUnitGraph. The HomeUnitGraph is a map from UnitId to HomeUnitEnv,
which contains information specific to each home unit.
* The HomeUnitEnv contains:
- A unit state, each home unit can have different package db flags
- A set of dynflags, each home unit can have different flags
- A HomePackageTable
* LinkNode: A new node type is added to the ModuleGraph, this is used to
place the linking step into the build plan so linking can proceed in
parralel with other packages being built.
* New invariant: Dependencies of a ModuleGraphNode can be completely
determined by looking at the value of the node. In order to achieve
this, downsweep now performs a more complete job of downsweeping and
then the dependenices are recorded forever in the node rather than
being computed again from the ModSummary.
* Some transitive module calculations are rewritten to use the
ModuleGraph which is more efficient.
* There is always an active home unit, which simplifies modifying a lot
of the existing API code which is unit agnostic (for example, in the
driver).
The road may be bumpy for a little while after this change but the
basics are well-tested.
One small metric increase, which we accept and also submodule update to
haddock which removes ExtendedModSummary.
Closes #10827
-------------------------
Metric Increase:
MultiLayerModules
-------------------------
Co-authored-by: Fendor <power.walross@gmail.com>
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously it was unclear whether req_shared_libs should require:
* that the platform supports dynamic library loading,
* that GHC supports dynamic linking of Haskell code, or
* that the dyn way libraries were built
Clarify by splitting the predicate into two:
* `req_dynamic_lib_support` demands that the platform support dynamic
linking
* `req_dynamic_hs` demands that the GHC support dynamic linking of
Haskell code on the target platform
Naturally `req_dynamic_hs` cannot be true unless
`req_dynamic_lib_support` is also true.
|
| |
|
|
|
| |
This eliminates some spurious platform-dependence due to static linking
(namely in UnsafeInfered02 due to dynamic-too).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This (big) commit finishes porting the GHC.Tc.Deriv module to support
the new diagnostic infrastructure (#18516) by getting rid of the legacy
calls to `TcRnUnknownMessage`. This work ended up being quite pervasive
and touched not only the Tc.Deriv module but also the Tc.Deriv.Utils and
Tc.Deriv.Generics module, which needed to be adapted to use the new
infrastructure. This also required generalising `Validity`.
More specifically, this is a breakdown of the work done:
* Add and use the TcRnUselessTypeable data constructor
* Add and use TcRnDerivingDefaults data constructor
* Add and use the TcRnNonUnaryTypeclassConstraint data constructor
* Add and use TcRnPartialTypeSignatures
* Add T13324_compile2 test to test another part of the
TcRnPartialTypeSignatures diagnostic
* Add and use TcRnCannotDeriveInstance data constructor, which introduces a
new data constructor to TcRnMessage called TcRnCannotDeriveInstance, which
is further sub-divided to carry a `DeriveInstanceErrReason` which explains
the reason why we couldn't derive a typeclass instance.
* Add DerivErrSafeHaskellGenericInst data constructor to DeriveInstanceErrReason
* Add DerivErrDerivingViaWrongKind and DerivErrNoEtaReduce
* Introduce the SuggestExtensionInOrderTo Hint, which adds (and use) a new
constructor to the hint type `LanguageExtensionHint` called `SuggestExtensionInOrderTo`,
which can be used to give a bit more "firm" recommendations when it's
obvious what the required extension is, like in the case for the
`DerivingStrategies`, which automatically follows from having enabled
both `DeriveAnyClass` and `GeneralizedNewtypeDeriving`.
* Wildcard-free pattern matching in mk_eqn_stock, which removes `_` in
favour of pattern matching explicitly on `CanDeriveAnyClass` and
`NonDerivableClass`, because that determine whether or not we can
suggest to the user `DeriveAnyClass` or not.
|
| |
|
|
| |
Copy-paste error in 38faeea1a94072ffd9f459d9fe570f06bc1da84a
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In order:
* Introduce the `PsErrUnknownOptionsPragma` diagnostic message
This commit changes the diagnostic emitted inside
`GHC.Parser.Header.checkProcessArgsResult` from an (erroneous) and
unstructured `DriverUnknownMessage` to a `PsErrUnknownOPtionsPragma`,
i.e. a new data constructor of a `PsHeaderMessage`.
* Add the `DriverUserDefinedRuleIgnored` diagnostic message
* Add `DriverUserDefinedRuleIgnored` data constructor
This commit adds (and use) a new data constructor to the `DriverMessage`
type, replacing a `DriverUnknownMessage` with it.
* Add and use `DriverCannotLoadInterfaceFile` constructor
This commit introduces the DriverCannotLoadInterfaceFile constructor for
the `DriverMessage` type and it uses it to replace and occurrence of
`DriverUnknownMessage`.
* Add and use the `DriverInferredSafeImport` constructor
This commit adds a new `DriverInferredSafeImport` constructor to the
`DriverMessage` type, and uses it in `GHC.Driver.Main` to replace one
occurrence of `DriverUnknownMessage`.
* Add and use `DriverCannotImportUnsafeModule` constructor
This commit adds the `DriverCannotImportUnsafeModule` constructor
to the `DriverMessage` type, and later using it to replace one usage of
`DriverUnknownMessage` in the `GHC.Driver.Main` module.
* Add and use `DriverMissingSafeHaskellMode` constructor
* Add and use `DriverPackageNotTrusted` constructor
* Introduce and use `DriverInferredSafeModule` constructor
* Add and use `DriverMarkedTrustworthyButInferredSafe` constructor
* Add and use `DriverCannotImportFromUntrustedPackage`
|
| |
|
|
|
|
|
|
| |
getProgName was used to append the name of the program (e.g. "ghc") to
printed error messages in the Show instance of GhcException. It doesn't
belong here as GHCi and GHC API users may want to override this behavior
by setting a different error handler. So we now call it in the
defaultErrorHandler instead.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit modifies interface files so that *only* direct information
about modules and packages is stored in the interface file.
* Only direct module and direct package dependencies are stored in the
interface files.
* Trusted packages are now stored separately as they need to be checked
transitively.
* hs-boot files below the compiled module in the home module are stored
so that eps_is_boot can be calculated in one-shot mode without loading
all interface files in the home package.
* The transitive closure of signatures is stored separately
This is important for two reasons
* Less recompilation is needed, as motivated by #16885, a lot of
redundant compilation was triggered when adding new imports deep in the
module tree as all the parent interface files had to be redundantly
updated.
* Checking an interface file is cheaper because you don't have to
perform a transitive traversal to check the dependencies are up-to-date.
In the code, places where we would have used the transitive closure, we
instead compute the necessary transitive closure. The closure is not
computed very often, was already happening in checkDependencies, and
was already happening in getLinkDeps.
Fixes #16885
-------------------------
Metric Decrease:
MultiLayerModules
T13701
T13719
-------------------------
|
| |
|
|
|
| |
Since `GeneralizedNewtypeDeriving` is considered unsafe, `DerivingVia`
should be as well.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit adds GhcMessage and ancillary (PsMessage, TcRnMessage, ..)
types.
These types will be expanded to represent more errors generated
by different subsystems within GHC. Right now, they are underused,
but more will come in the glorious future.
See
https://gitlab.haskell.org/ghc/ghc/-/wikis/Errors-as-(structured)-values
for a design overview.
Along the way, lots of other things had to happen:
* Adds Semigroup and Monoid instance for Bag
* Fixes #19746 by parsing OPTIONS_GHC pragmas into Located Strings.
See GHC.Parser.Header.toArgs (moved from GHC.Utils.Misc, where it
didn't belong anyway).
* Addresses (but does not completely fix) #19709, now reporting
desugarer warnings and errors appropriately for TH splices.
Not done: reporting type-checker warnings for TH splices.
* Some small refactoring around Safe Haskell inference, in order
to keep separate classes of messages separate.
* Some small refactoring around initDsTc, in order to keep separate
classes of messages separate.
* Separate out the generation of messages (that is, the construction
of the text block) from the wrapping of messages (that is, assigning
a SrcSpan). This is more modular than the previous design, which
mixed the two.
Close #19746.
This was a collaborative effort by Alfredo di Napoli and
Richard Eisenberg, with a key assist on #19746 by Iavor
Diatchki.
Metric Increase:
MultiLayerModules
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Dynamic-by-default was a mechanism to automatically select the -dynamic
way for some targets.
It was implemented in a convoluted way: it was defined as a flavour
option, hence it couldn't be passed as a global settings (which are
produced by `configure` before considering flavours), so a build system
rule was used to pass -DDYNAMIC_BY_DEFAULT to the C compiler so that
deriveConstants could infer it.
* Make build system has it disabled for 8 years (951e28c0625ece7e0db6ac9d4a1e61e2737b10de)
* It has never been implemented in Hadrian
* Last time someone tried to enable it 1 year ago it didn't work (!2436)
* Having this as a global constant impedes making GHC multi-target (see !5427)
This commit fully removes support for dynamic-by-default. If someone
wants to reimplement something like this, it would probably need to move
the logic in the compiler.
(Doing this would probably need some refactoring of the way the compiler
handles DynFlags: DynFlags are used to store and to pass enabled ways to
many parts of the compiler. It can be set by command-line flags, GHC
API, global settings. In multi-target GHC, we will use DynFlags to load
the target platform and its constants: but at this point with the
current DynFlags implementation we can't easily update the existing
DynFlags with target-specific options such as dynamic-by-default without
overriding ways previously set by the user.)
|
| |
|
|
| |
See #17018.
|
| |
|
|
|
|
|
|
|
|
| |
Fixes #19616.
This commit changes the `GHC.Driver.Errors.handleFlagWarnings` function
to rely on the newly introduced `DiagnosticReason`. This allows us to
correctly pretty-print the flags which triggered some warnings and in
turn remove the cruft around this function (like the extra filtering
and the `shouldPrintWarning` function.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit further expand on the design for #18516 by getting rid of
the `defaultReasonSeverity` in favour of a function called
`diagReasonSeverity` which correctly takes the `DynFlags` as input. The
idea is to compute the `Severity` and the `DiagnosticReason` of each
message "at birth", without doing any later re-classifications, which
are potentially error prone, as the `DynFlags` might evolve during the
course of the program.
In preparation for a proper refactoring, now `pprWarning` from the
Parser.Ppr module has been renamed to `mkParserWarn`, which now takes a
`DynFlags` as input.
We also get rid of the reclassification we were performing inside `printOrThrowWarnings`.
Last but not least, this commit removes the need for reclassify inside GHC.Tc.Errors,
and also simplifies the implementation of `maybeReportError`.
Update Haddock submodule
|
| |
|
|
| |
Fixes the Windows CI jobs. Requires update of the Win32 submodule.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
previously, `safeFlagCheck` would be happy to switch the `safeFlag` to
`False`, but not the other way around. This meant that after
:set -XGeneralizedNewtypeDeriving
:set -XNoGeneralizedNewtypeDeriving
in GHCi all loaded files would be still be infered as unsafe.
This fixes #19243.
This is a corner case, but somewhat relevant once ghci by default starts
with `GeneralizedNewtypeDeriving` on (due to GHC2021).
|
| |
|
|
| |
Fixes #18279. Bumps the `text` submodule.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
* support detection of slow ghc-bignum backend (to replace the detection
of integer-simple use). There are still some test cases that the
native backend doesn't handle efficiently enough.
* remove tests for GMP only functions that have been removed from
ghc-bignum
* fix test results showing dependent packages (e.g. integer-gmp) or
showing suggested instances
* fix test using Integer/Natural API or showing internal names
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Both `bindLHsTyVarBndrs` and `bindHsQTyVars` take two separate
`Maybe` arguments, which I find terribly confusing. Thankfully, it's
possible to remove one `Maybe` argument from each of these functions,
which this patch accomplishes:
* `bindHsQTyVars` takes a `Maybe SDoc` argument, which is `Just` if
GHC should warn about any of the quantified type variables going
unused. However, every call site uses `Nothing` in practice. This
makes sense, since it doesn't really make sense to warn about
unused type variables bound by an `LHsQTyVars`. For instance, you
wouldn't warn about the `a` in `data Proxy a = Proxy` going unused.
As a result, I simply remove this `Maybe SDoc` argument altogether.
* `bindLHsTyVarBndrs` also takes a `Maybe SDoc` argument for the same
reasons that `bindHsQTyVars` took one. To make things more
confusing, however, `bindLHsTyVarBndrs` also takes a separate
`HsDocContext` argument, which is pretty-printed (to an `SDoc`) in
warnings and error messages.
In practice, the `Maybe SDoc` and the `HsDocContext` often contain
the same text. See the call sites for `bindLHsTyVarBndrs` in
`rnFamInstEqn` and `rnConDecl`, for instance. There are only a
handful of call sites where the text differs between the
`Maybe SDoc` and `HsDocContext` arguments:
* In `rnHsRuleDecl`, where the `Maybe SDoc` says "`In the rule`"
and the `HsDocContext` says "`In the transformation rule`".
* In `rnHsTyKi`/`rn_ty`, where the `Maybe SDoc` says
"`In the type`" but the `HsDocContext` is inhereted from the
surrounding context (e.g., if `rnHsTyKi` were called on a
top-level type signature, the `HsDocContext` would be
"`In the type signature`" instead)
In both cases, warnings/error messages arguably _improve_ by
unifying making the `Maybe SDoc`'s text match that of the
`HsDocContext`. As a result, I decided to remove the `Maybe SDoc`
argument to `bindLHsTyVarBndrs` entirely and simply reuse the text
from the `HsDocContext`. (I decided to change the phrase
"transformation rule" to "rewrite rule" while I was in the area.)
The `Maybe SDoc` argument has one other purpose: signaling when to
emit "`Unused quantified type variable`" warnings. To recover this
functionality, I replaced the `Maybe SDoc` argument with a
boolean-like `WarnUnusedForalls` argument. The only
`bindLHsTyVarBndrs` call site that chooses _not_ to emit these
warnings in `bindHsQTyVars`.
|
| |
|
|
|
|
| |
There is no issue with nested splices as they do not require any compile
time code execution. All execution is delayed until the top-level
splice.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This commit partly reverts e69619e923e84ae61a6bb4357f06862264daa94b
commit by reintroducing Sf_SafeInferred SafeHaskellMode.
We preserve whether module was declared or inferred Safe. When
declared-Safe module imports inferred-Safe, we warn. This inferred
status is volatile, often enough it's a happy coincidence, something
which cannot be relied upon. However, explicitly Safe or Trustworthy
packages won't accidentally become Unsafe.
Updates haddock submodule.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This test uses TemplateHaskell causing GHC to build dynamic objects on
platforms where dynamic linking is available. However, Windows doesn't support
dynamic linking. Consequently the test would fail on Windows with:
```patch
--- safeHaskell/safeInfered/UnsafeInfered02.run/UnsafeInfered02.stderr.normalised 2019-06-04 15:10:10.521594200 +0000
+++ safeHaskell/safeInfered/UnsafeInfered02.run/UnsafeInfered02.comp.stderr.normalised 2019-06-04 15:10:10.523546200 +0000
@@ -1,5 +1,5 @@
-[1 of 2] Compiling UnsafeInfered02_A ( UnsafeInfered02_A.hs, UnsafeInfered02_A.o, UnsafeInfered02_A.dyn_o )
-[2 of 2] Compiling UnsafeInfered02 ( UnsafeInfered02.hs, UnsafeInfered02.o, UnsafeInfered02.dyn_o )
+[1 of 2] Compiling UnsafeInfered02_A ( UnsafeInfered02_A.hs, UnsafeInfered02_A.o )
+[2 of 2] Compiling UnsafeInfered02 ( UnsafeInfered02.hs, UnsafeInfered02.o )
UnsafeInfered02.hs:4:1:
UnsafeInfered02_A: Can't be safely imported!
```
The other approach I considered for this issue is to pass `-v0` to GHC.
However, I felt we should probably do this consistently for all of the tests in
this directory and this would take more time than I currently have.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GHC Proposal: 0013-unlifted-newtypes.rst
Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/98
Issues: #15219, #1311, #13595, #15883
Implementation Details:
Note [Implementation of UnliftedNewtypes]
Note [Unifying data family kinds]
Note [Compulsory newtype unfolding]
This patch introduces the -XUnliftedNewtypes extension. When this
extension is enabled, GHC drops the restriction that the field in
a newtype must be of kind (TYPE 'LiftedRep). This allows types
like Int# and ByteArray# to be used in a newtype. Additionally,
coerce is made levity-polymorphic so that it can be used with
newtypes over unlifted types.
The bulk of the changes are in TcTyClsDecls.hs. With -XUnliftedNewtypes,
getInitialKind is more liberal, introducing a unification variable to
return the kind (TYPE r0) rather than just returning (TYPE 'LiftedRep).
When kind-checking a data constructor with kcConDecl, we attempt to
unify the kind of a newtype with the kind of its field's type. When
typechecking a data declaration with tcTyClDecl, we again perform a
unification. See the implementation note for more on this.
Co-authored-by: Richard Eisenberg <rae@richarde.dev>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Closes #16062. When -dynamic-too is specified, reflect that in the
progress message, like:
$ ghc Main.hs -dynamic-too
[1 of 1] Compiling Lib ( Main.hs, Main.o, Main.dyn_o )
instead of:
$ ghc Main.hs -dynamic-too
[1 of 1] Compiling Lib ( Main.hs, Main.o )
|
| | |
|
| |
|
|
|
|
| |
As per https://prime.haskell.org/wiki/Libraries/Proposals/MonadFail
Coauthored-by: Ben Gamari <ben@well-typed.com>
|
| |
|
|
|
|
|
|
|
| |
Prevents some tests from failing just due to mismatched version numbers.
These version numbers shouldn't cause tests to fail, especially since
we *expect* them to be regularly incremented. The motivation for this
particular set of changes came from the changes that came along with
the `base` version bump in 8f19ecc95fbaf2cc977531d721085d8441dc09b7.
|
| |
|
|
|
| |
This eliminates most uses of run_command in the testsuite in favor of the more
structured makefile_test.
|
| |
|
|
| |
This reverts commit 76c8fd674435a652c75a96c85abbf26f1f221876.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Trac #16059 shows that when validity checking applications of type
synonyms, GHC sometimes wasn't checking the expanded type enough.
We must be careful, however, since checking both the expanded type as
well as the arguments to the type synonym can lead to exponential
blowup (see https://ghc.haskell.org/trac/ghc/ticket/16059#comment:4).
Nor can we omit checking either the expanded type or the argument for
correctness reasons.
The solution here is to introduce a new `ExpandMode` data type that
is plumbed through all of the type-validity-checking functions in
`TcValidity`. `ExpandMode` dictates whether we only check the
expanded type (`Expand`), only check the arguments (`NoExpand), or
both (`Both`). Importantly, if we check `Both` in the function for
validity checking type synonym applications, then we switch to
`NoExpand` when checking the arguments so as to avoid exponential
blowup. See `Note [Correctness and performance of type synonym validity
checking]` for the full story.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Mark arith011 as broken with integer-simple
As noted in #16091, arith011 fails when run against integer-simple with a
"divide by zero" exception. This suggests that integer-gmp and integer-simple
are handling division by zero differently.
* This also fixes broken_without_gmp; the lack of types made the previous
failure silent, sadly. Improves situation of #16043.
* Mark several tests implicitly depending upon integer-gmp as broken
with integer-simple. These expect to see Core coming from integer-gmp,
which breaks with integer-simple.
* Increase runtime timeout multiplier of T11627a with integer-simple
I previously saw that T11627a timed out in all profiling ways when run against
integer-simple. I suspect this is due to integer-simple's rather verbose heap
representation. Let's see whether increasing the runtime timeout helps.
Fixes test for #11627.
This is all in service of fixing #16043.
|
| |
|
|
| |
Spurious changes observed in a integer-simple build. In service of #16043.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This flag can be set to turn off the Safe Haskell checks.
Whether a module is marked Safe/Unsafe/Trustworthy is ignored when
this flag to set.
Reviewers: bgamari, tdammers
Reviewed By: tdammers
Subscribers: rwbarton, carter
GHC Trac Issues: #15920
Differential Revision: https://phabricator.haskell.org/D5360
|
