| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
| |
Several tests were failing in DEBUG mode, but fixing this
was easy: just pass $(TEST_HC_OPTS) in the relevant
Makefiles.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When inferring the correct abi-depends, we now look at all the package
databases in the stack, up to and including the current one, because
these are the ones that the current package can legally depend on. While
doing so, we will issue warnings:
- In verbose mode, we warn about every package that declares
abi-depends:, whether we actually end up overriding them with the
inferred ones or not ("possibly broken abi-depends").
- Otherwise, we only warn about packages whose declared abi-depends
does not match what we inferred ("definitely broken abi-depends").
Reviewers: bgamari
Reviewed By: bgamari
Subscribers: rwbarton, thomie, carter
GHC Trac Issues: #14381
Differential Revision: https://phabricator.haskell.org/D4729
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The script I used is included as testsuite/driver/kill_extra_files.py,
though at this point it is for mostly historical interest.
Some of the tests in libraries/hpc relied on extra_files.py, so this
commit includes an update to that submodule.
One test in libraries/process also relies on extra_files.py, but we
cannot update that submodule so easily, so for now we special-case it
in the test driver.
|
| |
|
|
| |
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The problem with ignore_output is that it hides errors for WAY=ghci.
GHCi always returns with exit code 0 (unless it is broken itself).
For example: ghci015 must have been failing with compile errors for
years, but we didn't notice because all output was ignored.
Therefore, replace all uses of ignore_output with either ignore_stderr
or ignore_stdout. In some cases I opted for adding the expected output.
Update submodule hpc and stm.
Reviewed by: simonmar
Differential Revision: https://phabricator.haskell.org/D2367
|
| |
|
|
|
|
|
|
|
|
| |
Also move the `cleanup` setting from `default_testopts` to `config`. The
`cleanup` setting is the same for all tests, hence it belongs in
`config`.
Reviewed by: austin
Differential Revision: https://phabricator.haskell.org/D2148
|
| |
|
|
| |
This seems necessary after 9634e24 (#11569).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of building a multiply indirected data structure and querying
it on every import, we now have two data structures moduleToPkgConf
and moduleToPkgConfAll. moduleToPkgConf is a single-level UniqFM that
is intended to be used for most valid imports; however, it does not
contain any information useful for error reporting. If an error is
occurred, we then query moduleToPkgConfAll, which contains a more
comprehensive view of the package database. This field is lazily
initialized (so this means we're retaining the package database list,
but this should be fine because we're already maintaining the entries
of the list.) Additionally, the full view doesn't keep track of a boolean
toggle for visibility/exposure anymore, but instead tracks the *provenance*
of how the module binding came to be (the ModuleOrigin data type).
Additionally, we move the logic for determining if a module is exposed
or not from Finder.lhs and put it in Packages.lhs; this information is
communicated via the LookupResult data type. Unfortunately, we can't
directly return a FindResult, because this data type is defined in
HscTypes which depends on Packages. This is going to change some more
in the near future when I add thinning/renaming to package flags; the
error messages will need to be more flexible.
I've also slightly changed the semantics of error messages for package
qualified imports. Previously, if we didn't find any package qualified
imports, but there were hidden modules in a *different* package, the error
message would prefer mentioning those as opposed to providing suggestions.
Now, if a module is hidden but in the wrong package, we won't mention it;
instead, it will get mentioned with the other module suggestions. I
was too lazy to write a test, but I can add one if people would like.
The module reexport bug was, package q reexported p:P as Conflict,
and package r reexported p:P2 as Conflict, this was *not* reported as
a conflict, because the old logic incorrectly decided that P and P2 were
the same module on account of being from the same package. The logic here
has been corrected.
Contains haddock submodule update.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
|
|
|
The general approach is to add a new field to the package database,
reexported-modules, which considered by the module finder as possible
module declarations. Unlike declaring stub module files, multiple
reexports of the same physical package at the same name do not
result in an ambiguous import.
Has submodule updates for Cabal and haddock.
NB: When a reexport renames a module, that renaming is *not* accessible
from inside the package. This is not so much a deliberate design choice
as for implementation expediency (reexport resolution happens only when
a package is in the package database.)
TODO: Error handling when there are duplicate reexports/etc is not very
well tested.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Conflicts:
compiler/main/HscTypes.lhs
testsuite/.gitignore
utils/haddock
|
