This should mean that concurrent updates to the store are now safe.
In practice it means working on separate projects at the same time is
safe, not concurrent builds within the same project.

Windows behavior for argument translation always quotes, which
is not so great for deterministic output.  And it wasn't really
necessary either, so just don't do it at all.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

In the corner case that a package has no components then if we allow it
to be handled as normal per-component nodes then the whole package would
vanish from the plan, which breaks later error reporting. Instead we
keep 0-component packages as whole-package nodes (as we do in a few
other cases like old Cabal versions or custom Setup scripts).

Later on we need to be able to look up package names that users have
requested and find what components they contain. It's ok to report that
a package has no components, but it's not ok to report that the package
does not exist at all. Hence it's important to preserve these packages
in the plan.

If we ever move fully to a per-component plan then we will need to
revisit this issue of how to represent packages with no components.

The run and repl commands only work with a single component as targets.
When the user gives multiple target selectors that refer to distinct
targets then we must report an error. It turns out that the information
we already had was not really sufficient to construct a helpful error
message. The information we had was the component targets that were
actually selected, but we actually want to know the target selectors
that gave rise to the selection of multiple targets.

So this patch extends the information we collect in the resolveTargets
function and stashes this info in the TargetProblemMultipleTargets
constructor, which will enable construction of useful error messages.

Normally a target like "pkg" does not select tests, benchmarks etc
(though this can be overridden by other configuration), but when a user
asks to repl/haddock "pkg:tests" then we should select tests
irrespective of defaults since that's the clear user intention.

This brings the repl and haddock commands into line with the build
command in this respect.

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.

It's true that in the way the Cmd* modules use readTargetSelectors with
resolveTargets, that these cases would be internal errors, it's more modular
for resolveTargets not to make that assumption and to report them like
other problems. We can report them as internal errors just as easily in the
Cmd* error reporting code.

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.

Refactor so that instead of two constructors TargetPackage and
TargetCwdPackage we have just TargetPackage with an extra bool-like field to
distinguish the two.

This simplifies things in the consumers of TargetSelector which
typically have to treat TargetPackage and TargetCwdPackage in the same
way.

Also eliminate the list field in TargetCwdPackage. We don't yet support
multiple .cabal files in one dir, and when we do we'll do the same for
the cwd targets as for other explicit targets. The only annoying thing
here is that we need to use a dummy package info value because the
representation does not allow for not having one. The tradeoff is still
worth it in terms of less verbose consumers.

Also adjust tests.

Take an extra arg to control where to start searching, not just process
current directory. This is mainly to make it easier to test without
having to mutate the cwd but is potentially useful generally for
cwd-independence.

Return more detailed info: not just the directory but return if it's an
implicit or an explict project root with a cabal.project file. In the
latter case also return the cabal.project file since its name can be
overridden. Then also adjust defaultDistDirLayout to take this more
detailed ProjectRoot type, thus avoiding having to duplicate the logic
about the location of the cabal.project file.

Change the behaviour so that if an explicit cabal.project file name is
given and it is not found then fail, rather than falling back to an
implicit project root style. This would seem to make most sense: if the
user specifies an explict cabal.project file then it'd be odd if we
silently ignore that if the user misspells it or something. The implicit
root default is really for the really simple case, not when users are
explicitly specifying stuff.

Also add a couple simple tests for findProjectRoot.

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

This means we can say things like:
cabal build tests     -- for the tests in the package in the cwd
cabal build foo:tests -- for the tests in package foo
cabal build all:benchmarks -- benchmarks in all packages in the project

The target selector matching now only returns packages that are local to
the project. This means that when resolving packages later, if a lookup
for the details of a package fails, then it's an internal error whereas
previously it just meant it was a package outside of the project.

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.

It was being used in one error message, in a place that will shortly be
replaced, and it would not make sense with upcomming changes to the
TargetSelector representation. So it's better to remove it now and fix
the place where it was being used later.

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.

Reduce it from info to debug and put it in a more sensible place where
we can also report if it's parallel or serial more easily.

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.

Having split getting the project config from constructing the install
plan we can simplify how the project config is handled. This lets us
pass just one set of ProjectConfig to resolveBuildTimeSettings rather
than parts of both the persistent and the cli ProjectConfig.

Previously we had a rebuildInstallPlan that does everything up to
producing the elaborated install plan. This included reading the project
config and all the local package description files etc.

It is useful to split this latter aspect out separately. The reason for
this is that we would really prefer to resolve command line build
targets without first having to run the solver and produce the
elaborated install plan. We would prefer to be able to report mistakes
in the build targets more or less instantly rather than having to wait
many seconds (or sometime more) before being able to report problems.
Worse, with the current scheme the solver may fail to find a solution
and so we'll end up reporting that rather than the problem with the
user's build target. Indeed problems with a build target are most likely
to happen when the project config is messed up (or not what users
expect, or before they understand the model) and those are the cases
where it's most likely that there is no project solution.

So this is a step towards being able to do all target resolution prior
to solving.

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.

We already have the SubComponentTarget type so we can use this to better
factor the BuildTarget type, and simplify conversions.

The --only-dependencies it is only used in build, so we move the
rendering of the errors that arise from that to that build command
module so the error message text can be more context specific.

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.

Previously the resolveUserBuildTargets would return a PackageName which
meant we would subsequently select all versions of that package that
occur in the project during target selection (resolveAndCheckTargets).
Using PackageId means we only pick one version (though in future we may
still need to disambiguate multiple instances, or targets from multiple
active profiles)

Previously it took the specification for the targets to build in terms
of PackageTarget which is a high-ish level specification of which
components to build. It is high level in the sense that it says things
like BuildDefaultComponents which still have to be elaborated into the
specific components.

This elaboration from the higher level intention of what to build into
what components to build specifically has to vary between different
commands (build, repl, run, test, bench) and it can also fail. These
features make it not a good fit to do within plan pruning. Instead it
is better to have plan pruning take the lower level specification of
what to build in terms of components and to do the conversion of high
level to low level separately. That will allow us to do it differently
for different commands and deal with failures better.

This patch does one step: it changes pruneInstallPlanToTargets from
taking [PackageTarget] to [ComponentTarget] and as an intermediate step
in refactoring it converts the existing elaboratePackageTargets code to
convert from the [PackageTarget] to [ComponentTarget] which is then used
by the calling code in ProjectOrchestration. The next step will be to
replace the elaboratePackageTargets with something more flexible and
that can handle errors better.

Edward Z. Yang authored 8 years ago and Edward Z. Yang committed 8 years ago

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>

Edward Z. Yang authored 8 years ago and Edward Z. Yang committed 8 years ago

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Edward Z. Yang authored 8 years ago and Edward Z. Yang committed 8 years ago

Now if you say cabal -v"info +callstacks", Cabal invocations
will also get call stacks.

There's a heinous hack to handle version of Cabal that don't
support the extended format.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>