Skip to content

Fix parse errors with --preview-dart-2 #1874

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 2 commits into from
Apr 18, 2018
Merged

Conversation

natebosch
Copy link
Member

We need the latest analyzer, front_end, and async to get past static
errors in these packages. Shelf needs to be updated to get the latest
async.

Fix a static error that is not caught by the analyzer around reassigning
the final stackTrace variable in a catch clause.

We need the latest analyzer, front_end, and async to get past static
errors in these packages. Shelf needs to be updated to get the latest
async.

Fix a static error that is not caught by the analyzer around reassigning
the final `stackTrace` variable in a catch clause.
@@ -68,7 +68,7 @@ class _PubHttpClient extends http.BaseClient {
streamedResponse = await _inner.send(request);
} on SocketException catch (error, stackTrace) {
// Work around issue 23008.
if (stackTrace == null) stackTrace = new Chain.current();
final defaultedStackTrace = stackTrace ?? new Chain.current();
Copy link
Member

Choose a reason for hiding this comment

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

Nit: var

I'd call the caught stack trace stackTraceOrNull and call this stackTrace, since this is used more frequently.

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

@@ -3,9 +3,9 @@ name: pub
dependencies:
# Note: Pub's test infrastructure assumes that any dependencies used in tests
# will be hosted dependencies.
analyzer: ">=0.25.0 <0.31.0"
analyzer: ^0.31.2-alpha.1
Copy link
Member

Choose a reason for hiding this comment

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

Are these tighter constraints really necessary? I generally try to keep constraints matching the actual APIs that are being used and let the version solver sort out which versions of the package are compatible with my Dart VM.

Copy link
Member Author

Choose a reason for hiding this comment

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

Would you prefer ">=0.31.2-alpha.1 <0.32.0"?

Copy link
Member

Choose a reason for hiding this comment

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

I'd prefer >=0.25.0 <0.32.0.

Copy link
Member

Choose a reason for hiding this comment

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

There are ZERO cases we care about where the analyzer version != the version in the Dart SDK.

Let's do everything we can to make sure the version ran on CI and dev machines matches that...

Copy link
Member

Choose a reason for hiding this comment

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

@kevmoo The same argument could be made for every version constraint here, but setting a policy of constantly revving them to match the SDK's versions is untenable. We have thorough integration tests in the SDK to make sure the versions work out, and otherwise we should treat this like any other package and only muck with version constraints when it's actually necessary.

Copy link
Member Author

Choose a reason for hiding this comment

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

synced offline. I think that "works with Dart 2" is a new behavior for the package that we want to start depending on, and I think it makes sense for our pub constraint to reflect that.

In the end, as we discussed, for this package it's mostly academic.

@natebosch natebosch merged commit 792ba08 into master Apr 18, 2018
@natebosch natebosch deleted the dart-2-parse-failures branch April 18, 2018 01:49
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