Skip to content

Various refactors in preparation for adding error reporting #1779

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 8 commits into from
Jan 19, 2018

Conversation

nex3
Copy link
Member

@nex3 nex3 commented Jan 11, 2018

Sending these out on their own to avoid dumping another giant pull
request.

See #912

This allows the solver to just throw an error on failure, rather than
wrapping it in an object to eventually get rethrown.
@nex3 nex3 requested a review from munificent January 11, 2018 00:01
@@ -0,0 +1,47 @@
// Copyright (c) 2017, the Dart project authors. Please see the AUTHORS file
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

year += 1

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

MissingFeatureException(String package, this.version, this.feature,
Iterable<Dependency> dependencies)
: super(package, dependencies);
String toString() => "Tough luck, Chuck!";
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add a TODO to put something real here?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

} else {
return "${terms.first.package.toTerseString()} is incompatible with "
"the current SDK";
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Might be useful to show the SDK version number here, no?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added a TODO.


String toString() {
if (cause == IncompatibilityCause.dependency) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you think of moving most of this logic into IncompatibilityCause? Something like:

class Incompability {
  String toString() => cause.describe(terms);
}

abstract class IncompatibilityCause {
  String describe(List<Term> terms);
}

class SdkCause implements IncompatibilityCause {
  String describe(List<Term> terms) {
    // ...
  }
}

?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It always weirds me out a bit to have a method like Incompatibility.describe() that's only ever supposed to be invoked by one specific caller... it feels like kind of the wrong separation of concerns.

@nex3 nex3 force-pushed the feature.solver.error-prep branch from f8eeafc to 38f8976 Compare January 19, 2018 00:16
nex3 added 7 commits January 18, 2018 16:18
This will help us explain version lock to users
Previously, we stopped conflict resolution as soon as we knew that no
solution could be found. Now we keep deriving new incompatibilities
until we reach one that says the root package can't be selected. This
allows us to provide a clearer line of reasoning about why version
solving failed to the end user.
The root package is now displayed without a version number or
constraint, and PackageRef now properly omits the source name for
hosted packages and not for other sources instead of vice versa.
This ensures that constraints constructed by the version
solver (rather than authored by humans) that look like ^ constraints
are displayed tersely.
Unlike the previous SolveFailure architecture, which had separate
subclasses for each type of failure, this includes a single
IncompatibilityCause that transitively describes the full reason that
the root package couldn't be selected successfully.
Non-derived incompatibilities now indicate their causes, and terms
with any constraints no longer list their constraints explicitly.
@nex3 nex3 force-pushed the feature.solver.error-prep branch from 38f8976 to 3cde899 Compare January 19, 2018 00:18
@nex3 nex3 merged commit 364484f into feature.solver Jan 19, 2018
@nex3 nex3 deleted the feature.solver.error-prep branch January 19, 2018 00:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants