Giacomo Stevanato

We have just been hit by this issue due to having different system fonts being among different contributors, making pdfs non-reproducible. Ideally the solution would be per-project (which rules out...

> note, I think `super let` could also solve the kind of problem this PR tackles, once we get some form of it in Rust. I'm not sure how this...

I've been using the `text(font: "", emptyset)` hack to work around this issue for a while, but it seems that the `main` branch version of `typst` warns against it ```...

This was an intentional change. It's also documented in the migration guide. https://bevyengine.org/learn/migration-guides/0-13-to-0-14/#app-changes > `App` is not `Send` anymore, but `SubApp` still is. See also the PR that made the...

I don't think this will solve the problem. Even if you manage to get some `TypeData` for a type, if the `TypeId` does not match the `TypeData` will fail to...

> `TypeInfo` and `TypeData` sets could probably be hashed and used to compare You likely don't want to hash `TypeData`s, since they don't have a canonical representation (e.g. the function...

I don't know what can be done about the debatable management of the crate, but at least the `emitter` issue is objectively a soundness issue and can be reported, no?

It's not clear to me what `commands.spawn(( FooConstructor::A( .... ), ))` would gain you over doing `commands.spawn(( FooConstructor::A( .... ).to_component(), ))` and directly spawning the component. > For avian, they...

While panicking is obviously unwanted, I feel like this focuses on the wrong issue as just changing `.single()` to `.get_single().unwrap()` won't change anything other than making it slightly more visible....

The access control is currently not enough since `Query` and `ResMut` don't conflict but still provide mutable access to the same data. The following test should not reach the `unreachable`:...