New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 753105 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner: ----
Closed: Aug 2017
Cc:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

Create a mojo typemapping for base::ProcessId.

Project Member Reported by erikc...@chromium.org, Aug 7 2017

Issue description

This allows us to avoid clunky conversion between base::ProcessId and mojo::common::mojom::ProcessId.
 
Cc: roc...@chromium.org
+ rockot.

Interesting. A type map already exists, and works for properties of other structs, e.g.:
https://cs.chromium.org/chromium/src/out/Debug/gen/services/resource_coordinator/public/interfaces/coordination_unit_introspector.mojom.h?type=cs&sq=package:chromium&l=238

struct ProcessInfo {
  mojo.common.mojom.ProcessId pid;
  array<int64> ukm_source_ids;
};
-->
class SERVICES_RESOURCE_COORDINATOR_PUBLIC_CPP_EXPORT ProcessInfo {
 public:
...
base::ProcessId pid;

But it did not apply to the generated virtual method, e.g.

AddSender(mojo.common.mojom.ProcessId pid, handle sender_pipe);   ->
virtual void AddSender(::mojo::common::mojom::ProcessIdPtr pid, mojo::ScopedHandle sender_pipe) = 0;

I'm assuming this is a limitation of the typemap system.
We need the mojom target deps to be accurate in order to deduce which type
mappings to apply. The mojom GN target which builds your mojom (the one
with AddSender) is most likely missing a dependency on
//mojo/common:common_custom_types.
I see, since otherwise the code in question wouldn't know which typemap variant to use?

I had read through
https://chromium.googlesource.com/chromium/src/+/master/mojo/public/cpp/bindings/README.md#Type-Mapping
before posting c#2, and didn't see any reference about updating deps. Did I miss something? 
It's not mentioned there, but in general the same rules apply to mojom as
any other target types. i.e. if a mojom in target A imports a mojom in
target B, target A needs to express a dependency on target B. Since A's
mojom can't possibly refer to the type-mapped mojom type without importing
B's mojom, this deps requirement is implicitly covered. Type-mapping works
as intended as long as that requirement is meant.

It is however pretty unfortunate that missing deps aren't more obvious.
I've filed  issue 753219  to track better detection of these kinds of
mistakes.

Sign in to add a comment