- 20 10月, 2020 1 次提交
-
-
由 skia-flutter-autoroll 提交于
-
- 18 10月, 2020 5 次提交
-
-
由 skia-flutter-autoroll 提交于
-
-
由 skia-flutter-autoroll 提交于
-
由 Jonah Williams 提交于
Fixes flutter/flutter#68377 Should be a nullable string. Looks like --null-assertions does not cover the native binding code.
-
由 skia-flutter-autoroll 提交于
-
- 17 10月, 2020 25 次提交
-
-
由 skia-flutter-autoroll 提交于
-
由 Ferhat 提交于
-
由 skia-flutter-autoroll 提交于
-
由 godofredoc 提交于
* Collect logs in the background. * Use fuchsia_ctl log_file option. * Delete the correct file. * Remove commented code.
-
由 skia-flutter-autoroll 提交于
-
由 Chinmay Garde 提交于
A version of this macro is present in most code-bases. The use of this macro must satisfy two requirements: 1: If reached, the process must be terminated in all runtime modes and at all optimization levels. 2: If the compiler requires a value to be returned from the function, encountering this macro should not make the compiler insist on a return value (since the process is about to die anyway). We used to have a version of this macro that wasn't widely used and didn't satisfy the two requirements. I have removed the same and another unused macro in fml/logging.h Fixes https://github.com/flutter/flutter/issues/68164.
-
由 skia-flutter-autoroll 提交于
-
由 Jason Simmons 提交于
-
由 skia-flutter-autoroll 提交于
-
由 Chris Bracken 提交于
This adds enforcement to the linter that all FLUTTER_NOLINT comments be of the form: // FLUTTER_NOLINT: https://github.com/flutter/flutter/issue/ID Every linter opt-out should have an associated bug describing what issue it works around so that others can work on eliminating it, or at least understanding the rationale and whether it's still relevant. This also reduces the likelihood of inadvertent copy-pasting into new files either because the author fails to spot it when copying the copyright block from another file, or assumes that it's necessary for some subcomponent of the engine. Bug: https://github.com/flutter/flutter/issues/68273
-
由 Chris Bracken 提交于
Eliminates FLUTTER_NOLINT where they can be landed without triggering lint failures.
-
由 skia-flutter-autoroll 提交于
-
由 Harry Terkelsen 提交于
-
由 Chris Bracken 提交于
In an upcoming patch, we'll enable enforcement that all FLUTTER_NOLINT comments include an issue link. This migrates the remaining uses to that format. Bug: https://github.com/flutter/flutter/issues/68273
-
由 George Wright 提交于
-
-
由 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
-
由 skia-flutter-autoroll 提交于
-
由 skia-flutter-autoroll 提交于
-
由 skia-flutter-autoroll 提交于
https://dart.googlesource.com/sdk.git/+log/e655b9a3839e..b58cfe5ab24e 2020-10-16 dart-luci-ci-builder@dart-ci.iam.gserviceaccount.com Version 2.11.0-230.0.dev If this roll has caused a breakage, revert this CL and stop the roller using the controls here: https://autoroll.skia.org/r/dart-sdk-flutter-engine Please CC dart-vm-team@google.com,asiva@google.com on the revert to ensure that a human is aware of the problem. To report a problem with the AutoRoller itself, please file a bug: https://bugs.chromium.org/p/skia/issues/entry?template=Autoroller+Bug Documentation for the AutoRoller is here: https://skia.googlesource.com/buildbot/+doc/master/autoroll/README.md
-
由 skia-flutter-autoroll 提交于
-
由 Chris Bracken 提交于
This removes most of the remaining FLUTTER_NOLINT comments and opts these files back into linter enforcement. I've filed https://github.com/flutter/flutter/issues/68273 to require that all FLUTTER_NOLINT comments be followed by a GitHub issue URL describing the problem to be fixed.
-
由 skia-flutter-autoroll 提交于
-
由 skia-flutter-autoroll 提交于
-
- 16 10月, 2020 9 次提交
-
-
由 Mehmet Fidanboylu 提交于
-
由 skia-flutter-autoroll 提交于
-
由 skia-flutter-autoroll 提交于
-
由 skia-flutter-autoroll 提交于
-
由 Kaushik Iska 提交于
-
由 Kaushik Iska 提交于
Changing it to shared_ptr and migrating the ownership from surface to platform view.
-
由 Chris Bracken 提交于
* Add multi-step IME support to TextInputModel This updates the platform-independent TextInputModel to add support for input method (abbreviated IM or IME) composing regions. In contrast to languages such as English, where keyboard input is managed keystroke-by-keystroke, languages such as Japanese require a multi-step input process wherein the user begins a composing sequence, during which point their keystrokes are captured by a system input method and converted into a text sequence. During composing, the user is able to edit the composing range and manage the conversion from keyboard input to text before eventually committing the text to the underlying text input field. To illustrate this, in Japanese, this sequence might look something like the following: 1. User types 'k'. The character 'k' is added to the composing region. Typically, the text 'k' will be inserted inline into the underlying text field but the composing range will be highlighted in some manner, frequently with a highlight or underline. 2. User types 'a'. The composing range is replaced with the phonetic kana character 'か' (ka). The composing range continues to be highlighted. 3. User types 'k'. The character 'k' is appended to the composing range such that the highlighted text is now 'かk' 4. User types 'u'. The trailing 'k' is replaced with the phonetic kana character 'く' (ku) such that the composing range now reads 'かく' The composing range continues to be highlighted. 5. The user presses the space bar to convert the kana characters to kanji. The composing range is replaced with '書く' (kaku: to write). 6. The user presses the space bar again to show other conversions. The user's configured input method (for example, ibus) pops up a completions menu populated with alternatives such as 各 (kaku: every), 描く (kaku: to draw), 核 (kaku: pit of a fruit, nucleus), 角 (kaku: angle), etc. 7. The user uses the arrow keys to navigate the completions menu and select the alternative to input. As they do, the inline composing region in the text field is updated. It continues to be highlighted or underlined. 8. The user hits enter to commit the composing region. The text is committed to the underlying text field and the visual highlighting is removed. 9. If the user presses another key, a new composing sequence begins. If a selection is present when composing begins, it is preserved until the first keypress of input is received, at which point the selection is deleted. If a composing sequence is aborted before the first keypress, the selection is preserved. Creating a new selection (with the mouse, for example) aborts composing and the composing region is automatically committed. A composing range and selection, both with an extent, are not permitted to co-exist. During composing, keyboard navigation via the arrow keys, or home and end (or equivalent shortcuts) is restricted to the composing range, as are deletions via backspace and the delete key. This patch adds two new private convenience methods, `editing_range` and `text_range`. The former returns the range for which editing is currently active -- the composing range, if composing, otherwise the full range of the text. The latter, returns a range from position 0 (inclusive) to `text_.length()` exclusive. * Move SetComposingLength to TextRange::set_* Adds set_base, set_extent, set_start, set_end methods to TextRange.
-
由 Kaushik Iska 提交于
-
由 skia-flutter-autoroll 提交于
-