This is more-or-less a revert of https://github.com/flutter/engine/pull/14011
This code never ended up being used outside of tests, and it's not how we handle asset loading at this point anyway.
I was hopeful we could kill off all runtime dependencies on Dart in `FML` when looking at this, but it looks like trace_event.h still wants to import dart_api_tools.h for some Dart enum types. This may or may not matter if we ever want to build FML for web/wasm. /cc @eyebrowsoffire. If we really need to do that, we can refactor the trace event stuff so that it has a web and Dart implementation that's selected at build time.
Introduce weak_nsobject from chromium.
There are some usages of weak_ptr wrapping Objective-C ids, weak_ptr is not really designed for ids and such usages are blocking the arc migration.
This PR mostly copies the weak_nsobject from chromium, at the same hash that we copied the ARC/MRC compatible scoped_nsobject: fd625125b8
To match how we used weak_ptr for those ids, I made some changes to the weak_nsobject:
- WeakNSObjects needs to be generated by a WeakNSObjectFactory. The WeakNSObjectFactory is owned by the objc class and acts as the generator of the WeakNSObjects. All the WeakNSObjects' derefing thread should be the same of the WeakNSObjectFactory's creation thread.
- chromuim's WeakNSObjects can be detached from the thread and re-attached to a new thread. To match our weak_ptr behavior, I changed WeakNSObjects to be only accessed from a single thread, the same as weak_ptr
This PR also moves the FlutterEngine to use WeakNSObject and updated related classes.
part of https://github.com/flutter/flutter/issues/137801
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
This PR is to address an issue we're seeing compiling flutter+impeller in certain configurations. Specifically:
1. Compiling with `clang-15`
2. using the GCC 13 backend to provide headers and cstdlib.
Via the `clang-15` version flag:
```
clang-15 -v
Debian clang version 15.0.7
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/11
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/12
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/13
Selected GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/13
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Candidate multilib: x32;@mx32
Selected multilib: .;@m64
```
We were building using the gcc 12 backend for a while, but picked up an update that forced us to 13, and then saw this issue.
The issue is seen as `uint8_t` being undefined as in the following partial messages:
```
hex_codec.cc:18:5: error: unknown type name 'uint8_t'
base32.cc:29:32: error: unknown type name 'uint8_t'
```
I'm not sure this is the cleanest fix, or if it might be better handled by adding some compile time switches, but I wanted to provide this to start conversation.
I'm also hoping to get a better idea of tests run against a PR. If there's any I should run manually we can discuss that here.
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Rather than doing a guess and check, since we have all of our cmds already stored we can add up the binding counts and allocate the exact descriptor size and populate them in one call.
Also makes render_pass and compute_pass share more (though not all) code.
Fixes the following:
c8aa0844f2 results in the following error appearing internally when compiling for Android:
```
In file included from fml/synchronization/sync_switch.cc:5:
./fml/synchronization/sync_switch.h:74:34: error: implicit instantiation of undefined template 'std::vector<fml::SyncSwitch::Observer *>'
mutable std::vector<Observer*> observers_;
^
<...>: note: template is declared here
class _LIBCPP_TEMPLATE_VIS vector;
^
1 error generated.
```
*List which issues are fixed by this PR. You must list at least one issue.*
b/306266542
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
The newly rolled version of clang-tidy is warning about some accesses to std::optional values. The function does a has_value check before accessing the values, but the analyzer does not detect that.
Work towards https://github.com/flutter/flutter/issues/134969.
These are all self-contained, so I bundled them all together.
All fixes are generated by `clang-tidy --fix`, and manual search/replace if that wasn't sufficient.
This is required to eventually land https://github.com/flutter/flutter/issues/134969 (lint header files).
No changes in behavior in this PR. Future steps:
- Change existing `LOG_X` references to `kLogX`
- Delete `LOG_X`
https://github.com/flutter/flutter/issues/134452
This patch parses the speed of all CPU data out of /proc and constructs a table that allows us to request high level CPU affinities: performance, efficiency, and not performance. These affinties are applied where appropriate during Android thread construction.
`UnMergeNowIfLastOne` is called during shell destruction. When there are other shells with threads unmerged and the current destroying shell with thread merged. `UnMergeNowIfLastOne` should unmerge the threads.
This PR Make `UnMergeNowIfLastOne` not only unmerge if the current merger is the last merger, but also unmerge if the current merger is the last merger that is merged.
Fixes https://github.com/flutter/flutter/issues/127168
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
If the wake happens while thread_ids_mutex is still held, then the test function may exit and destroy thread_ids_mutex before the pool thread task releases it.
Fixes https://github.com/flutter/flutter/issues/130344
Fixes https://github.com/flutter/flutter/issues/130036
Also fixes a potential issue where the shell wasn't getting destroyed at the end of the test.
Since no log is actually printed ont he second go, the destructor of `LogMessage` never clears the static pointer, and the next test that tries to print a log tries to print to that pointer which is now garbage.
We'd like to (or already are) using the concurrent message loop for high priority rendering tasks like PSO construction and render pass encoding. The default priority level for the engine managed concurrent message loop is 2, which is a significantly lower priority than the raster thread at -5. This is almost certainly causing priority inversion.
We must move back to dedicated runners so we can adjust thread priorities.
Fixes https://github.com/flutter/flutter/issues/128746
Prints a warning the first time a platform channel sends a message from the wrong thread with instructions/link to the site about how to fix this.
I ran into this while trying to get some printing going for places where we're creating thread local keys.
Supposedly, just including `<iostream>` should statically initialize `std::cout/cerr`, but it gets really hard to reason about whether your statically initialized code is going to be initialized before or after that happens. I tried making sure that the TU for `fml/logging.cc` did that initialization statically, but that also failed in the verison of the test included here (it passed in some other iterations that modified run_all_unittests.cc). We _could_ make sure it happens each and every time we touch `std::cerr` but ... we could also just use `fprintf(stderr, ...)` and it works just fine.
/cc @flar who ran into problems around this a little while back and was asking about it.
These keep turning up, so I did a little bash-fu to find them all.
```bash
grep -lL "#pragma once" $(grep -lL "#ifndef .*_H_" $(find . | grep "\.h$")) | cut -c 3-
```
This adds a gn flag (--backtrace, --no-backtrace) that defaults to
enabling backtraces, which drives a gn variable `enable_backtrace` which
is defaulted true for debug builds.
Backtrace collection is supported on Windows, and on POSIX-like
operating systems via execinfo.h. execinfo support exists in Android,
macOS/iOS, and in glibc and uclibc on Linux. musl libc notably does not
include execinfo support, so this provides an escape hatch to build with
backtrace_stub.cc for situations in which compile time support doesn't
exist.
Proposed as an alternative to
https://github.com/flutter/engine/pull/40958 by @selfisekai.
Issue: https://github.com/flutter/flutter/issues/124285
