Skip to content

Conversation

@tvolkert
Copy link
Contributor

This updates AppContext per the recommendations in #15352

Fixes #15352

@tvolkert tvolkert requested review from Hixie and yjbanov March 27, 2018 18:01
@tvolkert
Copy link
Contributor Author

@yjbanov @Hixie I committed this in steps to make it easier to review. I recommend viewing one commit at a time.

context.putIfAbsent(Usage, () => new DisabledUsage());
return runner(args);
});
T runInContext<T>(
Copy link
Contributor

Choose a reason for hiding this comment

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

I recommend making this return Future<T>.

This is because otherwise if you ever consider adding any async code here, and you create a Completer, you won't be able to complete it, because passing a Future to a Completer unwraps the future and causes a type error.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done

Copy link
Contributor

Choose a reason for hiding this comment

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

Or perhaps FutureOr<T>?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

No, runner had to be made FutureOr<T>, but this now definitely returns Future<T>

String toString() {
final StringBuffer buf = new StringBuffer('Dependency cycle detected: ');
buf.write(cycle.join(' -> '));
return buf.toString();
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: this is the same as: => 'Dependency cycle detected: ${cycle.join(' -> ')}'

},
);
expect(called, isTrue);
expect(value, 'child');
Copy link
Contributor

Choose a reason for hiding this comment

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

Did you mean to put called = true into a parent generator? I can't tell which check shows that the parent was consulted.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

No, this just exists to make sure that context.run didn't skip the body entirely. I originally had a "parent consulted" check, but that can't work, because if the parent is consulted, it means it had a generator, so the fallback would never be consulted...

Copy link
Contributor

Choose a reason for hiding this comment

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

Ah, got it. I was confused by the test description. I thought the test somehow tracked when the fallbacks are consulted relative to the parent.

context.putIfAbsent(Usage, () => new DisabledUsage());
return runner(args);
});
T runInContext<T>(
Copy link
Contributor

Choose a reason for hiding this comment

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

Or perhaps FutureOr<T>?

@yjbanov
Copy link
Contributor

yjbanov commented Mar 27, 2018

lgtm

},
);
expect(called, isTrue);
expect(value, 'child');
Copy link
Contributor

Choose a reason for hiding this comment

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

Ah, got it. I was confused by the test description. I thought the test somehow tracked when the fallbacks are consulted relative to the parent.

@tvolkert tvolkert merged commit 8d11f5c into flutter:master Mar 28, 2018
@tvolkert tvolkert deleted the context branch March 28, 2018 17:58
@Hixie
Copy link
Contributor

Hixie commented Mar 28, 2018

This mostly seems fine but I'm still a bit concerned that you sometimes run with a type that's a Future<x>. I think I would just always use async, that way it's always consistent about what you're doing.

The problem with sometimes expecting a Future<x> is that if you ever need to wrap it in something async, it's going to try to unpack the value, which will be a source of weird bugs.

Also sometimes you don't type the call to run<T>.

@tvolkert
Copy link
Contributor Author

#16034

tvolkert added a commit that referenced this pull request Mar 28, 2018
@aam
Copy link
Member

aam commented Mar 29, 2018

This seems to have broken running flutter with local engine:

flutter run -v --local-engine android_debug_unopt_x86

## exception

ArgumentError: Invalid argument(s): join(null, "../engine/src"): part 0 was null, but part 1 was not.

#0      _validateArgList (package:path/src/context.dart:1088:5)
#1      Context.join (package:path/src/context.dart:231:5)
#2      FlutterCommandRunner._findEnginePath (package:flutter_tools/src/runner/flutter_command_runner.dart:327:51)

Reason for the failure is that now we use Cache.flutterRoot in _findEnginePath before it had a chance to get initialized Cache.flutterRoot = fs.path.normalize(fs.path.absolute(flutterRoot));

@tvolkert
Copy link
Contributor Author

@aam, fixed in #16057

tvolkert added a commit that referenced this pull request Mar 29, 2018
It's required to be set before we detect local engine.

Was broken by #15984
DaveShuckerow pushed a commit to DaveShuckerow/flutter that referenced this pull request May 14, 2018
This updates AppContext per the recommendations in flutter#15352

Fixes flutter#15352
DaveShuckerow pushed a commit to DaveShuckerow/flutter that referenced this pull request May 14, 2018
DaveShuckerow pushed a commit to DaveShuckerow/flutter that referenced this pull request May 14, 2018
It's required to be set before we detect local engine.

Was broken by flutter#15984
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Aug 11, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

AppContext is prone to races

5 participants