1. 11 12月, 2020 1 次提交
  2. 09 12月, 2020 1 次提交
  3. 04 12月, 2020 1 次提交
  4. 03 12月, 2020 1 次提交
  5. 03 11月, 2020 1 次提交
  6. 27 10月, 2020 1 次提交
  7. 23 10月, 2020 1 次提交
    • G
      Reland: Migration to PlatformDispatcher and multi-window (#21932) · 6bc70e4a
      Greg Spencer 提交于
      This re-lands #20496 and #21780 after fixing the semantics-enabling code that was causing the post-submit web_smoke_test to fail.
      
      Below is the description from the original PR:
      
      This is a PR for converting the dart:ui code in the engine to use a multi-window API. The goal here is to convert from the window singleton to an API that has the concept of multiple windows. Also, I'm matching up the new PlatformDispatcher class to talk directly to the PlatformConfiguration class in the engine. I'm not attempting to actually enable creating multiple windows here, just migrate to an API that has a concept of multiple windows. The multi-window API in this PR currently only ever creates one window.
      
      The design doc for this change is here.
      
      The major changes in this PR:
      
      Move the platfom-specific attributes out of Window, and into the new PlatformDispatcher class that holds all of the platform state, so that the platform code need only update the configuration on this class.
      Create FlutterView, FlutterWindow, and SingletonFlutterWindow classes to separate out the concepts of a view (of which there may be multiple in a window), a window (of which there may be multiple on a screen, and they host views), and a window where there is only ever expected to be one (this hosts the entire API of the former Window class, and will eventually be the type of the window singleton).
      Next step after this PR lands:
      
      Remove the Window class entirely (it is replaced by SingletonFlutterWindow). Some minor changes in the Framework are needed to switch to using SingletonFlutterWindow directly first.
      
      The Window class still exists in this PR, but will be removed as soon as the framework is converted to point to the SingletonFlutterWindow class instead. They share the same API, just have different names (Window is currently a subclass of SingletonFlutterWindow). The intention is that the Window name will be freed up to use as a widget class name in the framework for managing windows. The singleton called window will remain, and keep the same API it has now.
      6bc70e4a
  8. 22 10月, 2020 2 次提交
    • C
      Isolates launched by the engine instance use the settings of that instance. (#22052) · defa8be2
      Chinmay Garde 提交于
      This regression was introduced in https://github.com/flutter/engine/pull/21820
      for sound-null safety. The settings used to launch the VM were incorrectly used
      to determine the isolate lifecycle callbacks. Since the first shell/engine in
      the process also starts the VM, these objects are usually identical. However,
      for subsequent engine shell/engine launches, the callbacks attached to the new
      settings object would be ignored. The unit-test harness is also structured in
      such a way that each test case tears down the VM before the next. So all
      existing tests created a bespoke VM for the test run, and, the tests that did
      create multiple isolates did not also test attaching callbacks to the settings
      object.
      
      Fixes https://github.com/flutter/engine/pull/22041
      defa8be2
    • C
      Ensure root isolate create callback is invoked before the isolate is in the running phase. (#22041) · f459a866
      Chinmay Garde 提交于
      Embedders that have access to the Dart native API (only Fuchsia now) may perform
      library setup in the isolate create callback. The engine used to depend on the
      fact the root isolate entrypoint is invoked in the next iteration of message
      loop (via the `_startIsolate` trampoline in `isolate_patch.dart`) to ensure that
      library setup occur before the main entrypoint was invoked. However, due to
      differences in the way in which message loops are setup in Fuchsia, this
      entrypoint was run before the callback could be executed. Dart code on Fuchsia
      also has the ability to access the underlying event loops directly. This patch
      moves the invocation of the create callback to before user dart code has a
      chance to run. This difference in behavior on Fuchsia became an issue when the
      isolate initialization was reworked in https://github.com/flutter/engine/pull/21820
      for null-safety.
      
      Another issue was discovered in that the callback was being invoked twice, I
      fixed that too and added a test.
      
      Fixes https://github.com/flutter/flutter/issues/68732
      f459a866
  9. 21 10月, 2020 1 次提交
  10. 20 10月, 2020 1 次提交
  11. 18 10月, 2020 1 次提交
  12. 17 10月, 2020 2 次提交
    • C
      Eliminate unnecessary linter opt-outs (#21935) · 49c35b61
      Chris Bracken 提交于
      Eliminates FLUTTER_NOLINT where they can be landed without triggering
      lint failures.
      49c35b61
    • C
      Enable loading snapshots with sound null safety enabled. (#21820) · 5bd7260a
      Chinmay Garde 提交于
      Snapshots compiled with sound null-safety enabled require changes to the way in
      which isolates are launched. Specifically, the `Dart_IsolateFlags::null_safety`
      field needs to be known upfront. The value of this field can only be determined
      once the kernel snapshot is available. This poses a problem in the engine
      because the engine used to launch the isolate at shell initialization and only
      need the kernel mappings later at isolate launch (when transitioning the root
      isolate to the `DartIsolate::Phase::Running` phase). This patch delays launch of
      the isolate on the UI task runner till a kernel mapping is available. The side
      effects of this delay (callers no longer having access to the non-running
      isolate handle) have been addressed in this patch. The DartIsolate API has also
      been amended to hide the method that could return a non-running isolate to the
      caller.  Instead, it has been replaced with a method that requires a valid
      isolate configuration that returns a running root isolate. The isolate will be
      launched by asking the isolate configuration for its null-safety
      characteristics.
      
      A side effect of enabling null-safety is that Dart APIs that work with legacy
      types will now terminate the process if used with an isolate that has sound
      null-safety enabled. These APIs may no longer be used in the engine. This
      primarily affects the Dart Convertors in Tonic that convert certain C++ objects
      into the Dart counterparts. All known Dart Converters have been updated to
      convert C++ objects to non-nullable Dart types inferred using type traits of the
      corresponding C++ object. The few spots in the engine that used the old Dart
      APIs directly have been manually updated. To ensure that no usage of the legacy
      APIs remain in the engine (as these would cause runtime process terminations),
      the legacy APIs were prefixed with the `DART_LEGACY_API` macro and the macro
      defined to `[[deprecated]]` in all engine translation units. While the engine
      now primarily works with non-nullable Dart types, callers can still use
      `Dart_TypeToNonNullableType` to acquire nullable types for use directly or with
      Tonic. One use case that is not addressed with the Tonic Dart Convertors is the
      creation of non-nullable lists of nullable types. This hasn’t come up so far in
      the engine.
      
      A minor related change is reworking tonic to define a single library target.
      This allows the various tonic subsystems to depend on one another. Primarily,
      this is used to make the Dart convertors use the logging utilities. This now
      allows errors to be more descriptive as the presence of error handles is caught
      (and logged) earlier.
      
      Fixes https://github.com/flutter/flutter/issues/59879
      5bd7260a
  13. 13 10月, 2020 2 次提交
    • Y
      Revert "Migration to PlatformDispatcher and multi-window #20496" (#21792) · c2938d06
      Yuqian Li 提交于
      * Revert "Fix documentation build for window changes. (#21780)"
      
      This reverts commit 931a0468.
      
      * Revert "Migration to PlatformDispatcher and multi-window (#20496)"
      
      This reverts commit 85b0031f.
      c2938d06
    • Y
      Reland "Create root isolate asynchronously (#20142)" (#21747) · 190fd8eb
      Yuqian Li 提交于
      This reverts commit 5585ed99.
      
      Additionally, the following _flutter.runInView deadlock is fixed.
      
      Previously, a deadlock would occur when service protocol
      _flutter.runInView is used to restart the engine wihtout tearing down
      the shell: the shared mutex of the service protocol will be locked
      during the restart as it's in the middle of handling a service protocol
      message; if ServiceProtocol::AddHandler is also called during the
      restart, the deadlock happens as AddHandler also requires such lock.
      
      test/integration.shard/background_isolate_test.dart would fail
      without this fix.
      190fd8eb
  14. 10 10月, 2020 1 次提交
    • G
      Migration to PlatformDispatcher and multi-window (#20496) · 85b0031f
      Greg Spencer 提交于
      This is a PR for converting the dart:ui code in the engine to use a multi-window API. The goal here is to convert from the window singleton to an API that has the concept of multiple windows. Also, I'm matching up the new PlatformDispatcher class to talk directly to the PlatformConfiguration class in the engine. I'm not attempting to actually enable creating multiple windows here, just migrate to an API that has a concept of multiple windows. The multi-window API in this PR currently only ever creates one window.
      
      The design doc for this change is here.
      
      The major changes in this PR:
      
      Move the platfom-specific attributes out of Window, and into the new PlatformDispatcher class that holds all of the platform state, so that the platform code need only update the configuration on this class.
      Create FlutterView, FlutterWindow, and SingletonFlutterWindow classes to separate out the concepts of a view (of which there may be multiple in a window), a window (of which there may be multiple on a screen, and they host views), and a window where there is only ever expected to be one (this hosts the entire API of the former Window class, and will eventually be the type of the window singleton).
      Next step after this PR lands:
      
      Remove the Window class entirely (it is replaced by SingletonFlutterWindow). Some minor changes in the Framework are needed to switch to using SingletonFlutterWindow directly first.
      
      The Window class still exists in this PR, but will be removed as soon as the framework is converted to point to the SingletonFlutterWindow class instead. They share the same API, just have different names (Window is currently a subclass of SingletonFlutterWindow). The intention is that the Window name will be freed up to use as a widget class name in the framework for managing windows. The singleton called window will remain, and keep the same API it has now.
      85b0031f
  15. 12 9月, 2020 2 次提交
    • C
      Clean up C++ includes (#21127) · 08dabe96
      Chris Bracken 提交于
      Cleans up header order/grouping for consistency: associated header, C/C++ system/standard library headers, library headers, platform-specific #includes.
      
      Adds <cstring> where strlen, memcpy are being used: there are a bunch of places we use them transitively.
      
      Applies linter-required cleanups. Disables linter on one file due to included RapidJson header. See https://github.com/flutter/flutter/issues/65676
      
      This patch does not cover flutter/shell/platform/darwin. There's a separate, slightly more intensive cleanup for those in progress.
      08dabe96
    • C
      Prefer C++ standard headers to their C counterpart (#21091) · 16b900b6
      Chris Bracken 提交于
      We currently use a mix of C standard includes (e.g. limits.h) and their
      C++ variants (e.g. climits). This migrates to a consistent style for all
      cases where the C++ variants are acceptable, but leaves the C
      equivalents in place where they are required, such as in the embedder
      API and other headers that may be used from C.
      16b900b6
  16. 10 9月, 2020 1 次提交
  17. 09 9月, 2020 1 次提交
  18. 07 9月, 2020 1 次提交
    • C
      Enable lazy-async-stacks by-default in all modes (Take 3) (#20895) · 575a5194
      Clement Skau 提交于
      Lazy async stacks were already enabled by-default in AOT mode in [0] - which made the
      gen_snapshot invocations use "--lazy-async-stacks --no-causal-async-stacks".
      
      This change does the same with the engine defaults, which makes this be enabled
      by-default in JIT mode as well.
      
      See go/dart-10x-faster-async for more information.
      
      This is a re-land: A fix for what we believe to have caused the last revert has landed upstream in Dart in dart-lang/sdk@0004589
      
      [0] flutter/flutter@3478232
      575a5194
  19. 04 9月, 2020 1 次提交
  20. 03 9月, 2020 1 次提交
  21. 02 9月, 2020 2 次提交
  22. 26 8月, 2020 1 次提交
    • D
      Revert hint_freed (#20746) · 4a88d5e1
      Dan Field 提交于
      This caused over-aggressive GCs, which vastly increased CPU usage benchmarks.
      
      * Revert "fix build (#20644)"
      
      This reverts commit b59793ee.
      
      * Revert "Hint freed (#19842)"
      
      This reverts commit 3930ac1b.
      4a88d5e1
  23. 20 8月, 2020 2 次提交
  24. 14 8月, 2020 1 次提交
  25. 13 8月, 2020 1 次提交
  26. 08 8月, 2020 1 次提交
  27. 04 8月, 2020 1 次提交
  28. 01 8月, 2020 2 次提交
  29. 31 7月, 2020 1 次提交
  30. 30 7月, 2020 1 次提交
    • S
      Manual roll of Dart from 24c7666def...40fd1c456e (#20092) · b955e15e
      Siva 提交于
      * Manual roll of Dart from 24c7666def...40fd1c456e
      
      dart-lang/sdk@40fd1c456e Revert "[dart:io] Add Abort() on HttpClientRequest"
      dart-lang/sdk@17d7296a42 [vm/nnbd/bytecode] Fix reuse of type arguments in bytecode
      dart-lang/sdk@58b6f40c73 Issue 42797. Understand in legacy libraries that a function returning Never (in Null Safety library) never returns. (reland)
      dart-lang/sdk@fc8a6d9f9b [VM/compiler] Dereference TypeRef literal when propagating constants.
      dart-lang/sdk@0689ec527a Move "test.dart" (well, most of its contents) into pkg/test_runner.
      dart-lang/sdk@1094b3c61d Prepare static error test updater tool to handle web tests.
      dart-lang/sdk@b258585f2f [observatory] Migrate from deprecated isInstanceOf to isA.
      dart-lang/sdk@dfe1d9b682 Disable OverrideContributor for Cider.
      dart-lang/sdk@aea99b2f5c scope debug property assist to Diagnosticables
      dart-lang/sdk@4b96f20a79 [dart:io] Add Abort() on HttpClientRequest
      dart-lang/sdk@1b1a39708c [build] Use frameworks instead of libs
      dart-lang/sdk@3fef522496 Revert "Reland "[vm] Replaces fuchsia.deprecatedtimezone""
      dart-lang/sdk@8c664d4f3f Revert "Issue 42797. Understand in legacy libraries that a function returning Never (in Null Safety library) never returns."
      dart-lang/sdk@2efb5bebc7 [ dart:_http ] Fix typo in HTTP response timeline event
      dart-lang/sdk@0884dae36c Revert "Fix the #include path for ICU headers"
      dart-lang/sdk@5171534e81 Scope tweaks. Report REFERENCED_BEFORE_DECLARATION in more places.
      dart-lang/sdk@6bba75079a Issue 42797. Understand in legacy libraries that a function returning Never (in Null Safety library) never returns.
      dart-lang/sdk@b4ebbb7f5c [build] Update gn to match Fuchsia
      dart-lang/sdk@cb428a7a02 [dart2js] Remove old bug work around in collector.
      dart-lang/sdk@08663c20ab Change flutter patch to match existing DEPS on master branch
      dart-lang/sdk@146ad014d9 update js/meta for the 2.10 dev sdk
      dart-lang/sdk@488c718793 [co19] Roll co19 to d79951e06e443213243e54c2c32694b79a221b65
      dart-lang/sdk@ba20edd7be Add patch for flutter-engine when changing to version 2.10
      
      * Rev buildroot to latest version.
      
      * Update license.
      
      * update.
      
      * Update gn revision.
      
      * Format BUILD.gn files as the gn revision has been updated.
      b955e15e
  31. 29 7月, 2020 1 次提交
  32. 23 7月, 2020 1 次提交
  33. 14 7月, 2020 1 次提交
    • D
      fuchsia: Enable most unittests (#19583) · 9353692c
      David Worsham 提交于
      Tweak the primary flutter build rule so that fuchsia is more similar to
      other platforms in how tests and the shell are built.
      
      Only embedder_unittests and GLFW tests are disabled on Fuchsia now.
      
      TEST: Ran unittests on host/fuchsia; workstation on fuchsia
      BUG: fxb/53847, fxb/54056
      9353692c