* Collect logs in the background.

* Use fuchsia_ctl log_file option.

* Delete the correct file.

* Remove commented code.

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.

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

Eliminates FLUTTER_NOLINT where they can be landed without triggering
lint failures.

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

This reverts commit 1bc025d6.

See https://github.com/flutter/flutter/issues/68315

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

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

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.

Changing it to shared_ptr and migrating the ownership from surface
to platform view.

* 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 'かｋ'
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.

Adds tests for TextRange::Contains(const TextRange&) where the range
being tested spans the base/extent of the testing range.

This was originally intended to land in #21854, but it seems I didn't
push the additional tests before landing.

This fixes Windows build on goma.

Rolls in buildroot change https://github.com/flutter/buildroot/pull/406 https://github.com/flutter/engine/pull/21884 by stuartmorgan which removes the /FC flag in Windows builds. That flag is incompatible with upstream goma changes.

See: https://source.chromium.org/chromium/chromium/src/+/2e6d17c6948b2ca1e4dbd6bf15fcb52d32fa338d

* WIP on Paragraph

* WIP skparagraph

* Add more Paragraph features in CanvasKit mode

* Fix addRoundRect test

* Respond to review comments

* Remove unused (and potentially harmful) getters from Sk classes