GitLab

It's non-obvious that the expected way to pass command line options to
a test suite would be a different command, so mention it explicitly.

Closes #5416.

See #4737

This reverts commit 71131cf4.

The PackageId and ComponentName are already part of the existing
AvailableTarget record argument.

We need to eliminate this redundancy because for new kinds of target
selectors we will not have the PackageId and ComponentName from the
selector, only from the AvailableTarget selected.

Previously the TargetSelector type had a type param for the type of the
package that it referred to. In particular we used it with types like:

type Matcher  = ... -> Match (TargetSelector KnownPackage)
type Renderer = TargetSelector PackageId -> ...

However we are about to extend the TargetSelector so that it does not
just refer to one form of package (e.g. KnownPackage) but can refer to
packages via various different forms and partial information. So it no
longer makes sense to have TargetSelector be paramaterised by the
different states of the one kind of package it refers to, as there are
now many kinds. So in preparation for that we simplify it so that it is
equivalent to always using TargetSelector PackageId, and we remove the
type paramater.

Consolodate the three copies of it.

Return a monomorphic TargetsMap from selectPlanSubset and put it in the
final ProjectBuildContext.

This causes slight duplication in CmdRun.hs, but not as bas as when we
didn't return anything. In exchange, the final return type is much
simpler.

Note that CmdConfigure returns an empty TargetsMap, as configure doesn't
accept targets.

Previously, the extraction of the target from the targetStrings was done
twice: inside the function passed to 'runProjectPreBuildPhase' and right
after it.

Now 'runProjectPreBuildPhase' is able to return information from that
function, and the duplication was removed, along with some assumptions
about the number of targets.

Formatting into reasonably readable error messages for all of the
TargetProblem cases for each command. There's quite a bit of overlap
possible here which we put into common code in a new module.

Also take the opportunity to move some other error formatting into the
shared module.

This covers some of the positive cases of target selector resolution
and pretty much all of the negative cases for each command.

The case of there being no targets at all is now handled by the target
selector stage.

Asking to test/bench/run a file or module does not make sense.
Users can only ask for a whole component.

This is the function that implements the semantics of the target
selector matching for each command.

Introduce and use utils for target filtering and selection.

Rename several of the error constructors to be consistent. For the test,
bench and run commands, add a distinction between there being no targets
at all and none of the right kind.

Document the selectPackageTargets top level and cases, and
selectComponentTarget. Also document the TargetProblem and constructors.

Previously they took a TargetSelector that would always be a
TargetComponent constructor, which meant that if we were interested in
the content then we'd have to do partial pattern matching. Instead they
now take all the contents of the TargetComponent as separate args which
means no partial patterns and easy access to the parts.

Also where relevant, put the TargetComponent contents into the
TargetProblemCommon and TargetProblem constructors.

Each Cmd* module defines its own type for representing the error
conditions in selecting package and component targets. Each one has a
constructor for the problems that are common to them all, which is
shared in the ProjectOrchestration module.

Rename these types so that ProjectOrchestration defines the type
TargetProblemCommon and each of the others defines their own local type
each named TargetProblem.

Also make one step closer to proper error reporting for all these types
by using die' and verbosity appropriately. Remove the old unused and
incomplete error reproting code for TargetProblemCommon.

Add a few Eq and Ord instances while we're at it. They'll be needed for
testing and other things.

So the DistDirLayout now contains the root dir of the project as a
whole, which eliminates the need to pass it separately in several cases.
It also contains the location of the cabal.project file, which again
avoids having to pass it around.

In part these changes were to allow the elimination of uses of the
legacy config types in the new-build code. The idea is that the legacy
config types are only used by conversion into the new config types, and
then only the new types are used in the new code.

The stuff about the new-build/nix-local-build beta

Extend TargetSelector with a TargetAllPackages constructor with the
corresponding concrete command line syntax 'all'. The interpretation of
this is extended for all commands to be the same as if the list of all
packages local to the project were given.

Since the concrete syntax for the meta-target 'all' can in principle
clash with a package 'all' or a component 'all', this short form of
syntax is made to be ambigious with the existing short forms for
packages or components, and new more qualified forms are added.

This means that a user writing 'cabal build all' in a project where
there is a local package 'all' or a component 'all' in the package in
the cwd (but not any package 'all' as a dependency or any component
'all' in any package other than the one in the cwd), will be informed
that the syntax is ambigious and will be told the more qualified forms
of the possible targets. These would be ':all' and 'pkg:all'. The use of
the usual ':' separator with an empty string is the explicit indicator
of a meta namespace. Since 'pkg:all' itself is also potentially
ambigious with a package named 'pkg' containing a component 'all' then
there is a further qualified form ':pkg:all' to select the package named
'all'.

This more qualified syntax need only be used in these highly unusual
ambigious cases and the user will be informed. The intention, as has
been the case previously, is to allow a normal syntax that is short and
convenient but potentially ambigious in rare cases, while still allowing
all cases to be expressed unambigiously.

So there's now just one error type rather than two, and errors are
returned rather than reported directly.

Now that we have squashed together the two phases of the target
selector parsing and resolving, we also want to do the same with the
error reporting for the two phases. And to make it possible to customise
the error messages for different commands we have the reporting being
done explicitly and separately.

This means that in the majority of cases we can report errors in the
command line arguments prior to running the solver. This is a much
better state of affairs. Previously we had to wait many seconds (or
sometime more) before being able to report problems. Worse, with the
previous scheme the solver may fail to find a solution and so we'd
end up reporting that rather than the problem with the user's target.

This is part of the refactoring to resolve command line build targets
without first having to run the solver and produce the elaborated
install plan.

Previously runProjectPreBuildPhase would do all the early steps
including finding the project root and establishing the project
config and the local packages. This patch splits those early steps
out into a separate pass in the project orchestration. It also
eliminates the need for the hookPrePlanning and since there's then
only one hook left we don't bother to name the PreBuildHooks.

We're going to generalise it and the name will no longer be appropriate.
We'll add the ability to select all packages, or to select only certain
kinds of components in a package. So this makes it less like a resolved
target and more or an expression that needs further work to resolve to
a set of targets.

So far they just build the exe bench and don't do the next steps,
but they do at least select the right components to build.

Also bring the existing test command into sync with the others.

Instead of expressing the intention in terms of PackageTargets, it now
takes helper functions that select the components to use for a package
target or a component target. These helpers are given the set of
AvailableTargets and they can do error checking and return failures.

This allows the build,configure,haddock,repl implementations to have
their own behaviour and error checking and reporting for selecting
targets.

The full details of error reporting are not covered yet.

selectTargets would also prune to to the targets, and optionally prune
to dependencies only. These aspects are now pulled out into the callers
in the various Cmd{Build,Repl,etc} modules.

It will make more sense to do it this way once we're doing more explicit
error checking in the callers.

Edward Z. Yang authored Feb 13, 2017 and Edward Z. Yang committed Feb 19, 2017

This flips error handling around, so that 'die' now can format
an error message with call stacks and markers before raising
it to the top handler.  The top handler detects "verbatim"
deaths and prints them without formatting.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>