Improvements to execution order ambiguity reporting #4299

alice-i-cecile · 2022-03-23T05:22:27Z

Context

This PR was largely completed by @alfonsolage in #2766. I've simply rebased it and put a few finishing touches on it to get it over the finish line.

Massive thanks and full credit for all his hard work.

Objective

Execution order ambiguities suck, but our existing tool to discover them isn't very nice.
It also isn't very discoverable.
Fixes Simple improvements to ambiguity reporting clarity #1484

Solution

Number the reported ambiguities, to make them easier to discuss in a team.
Display function signatures of conflicting systems.
Explain which component(s) / resource(s) the systems are conflicting on.
Report ambiguities where all pairwise combinations of systems conflict on the same data as a group.
Create a simple .ignore_all_ambiguities() method that causes a system to be ignored completely in the ambiguity checker. This would only be useful for inconsequential systems like particle effect creation.
Replace ambiguity sets with a simple .ambiguous_with(system_label) method, which allows your system to be ambiguous with the provided label (or system, via [Merged by Bors] - Auto-label function systems with SystemTypeIdLabel #4224).
Provide an "X unresolved ambiguities detected" message that runs by default. Rather than toggling ambiguity detection on/off, have three states: off / minimal / verbose. This would provide discoverability that system ambiguities are a thing and let developers see when the change that they just made added / removed some ambiguities at a glance.
Provide an way to ignore/filter crates when using ambiguity checker.
By default, ambiguity checker should ignore internal bevy crates.
Improve docs.
Add an example of using ambiguity reporting
Add a WarnInternal reporting level, and included an example to the tools folder that reports all of the Bevy-internal ambiguities. Should be helpful for developers until we quash the last few.
Add a Forbid reporting level, for developers who prefer to force themselves to fix ambiguities ASAP.
Add a Deny reporting level, which reports literally every ambiguity and panics, for applications that need true determinism.
Use short version of system and type names, rather than full path (generally, this is just noise and makes the output much harder to read).
Use tracing's warn and error macros, rather than println.

Changelog

Execution order ambiguity reporting has been significantly improved and a minimal report informing you of the number of ambiguous system pairs present in your schedule is now on by default.

It is now much easier to disable false positive ordering ambiguities, bevy-internal ambiguities are silenced by default and the output is much easier to read and act on.

Sample output:

One of your stages contains 4 pairs of systems with unknown order and conflicting data access.
You may want to add `.before()` or `.after()` constraints between some of these systems to prevent bugs.

1. `system_b` conflicts with `system_e` on ["MyResource"]
2. `system_b` conflicts with `system_d` on ["MyResource", "MyOtherResource"]
3. `system_e` conflicts with `system_c` on ["MyResource"]
4. `system_d` conflicts with `system_c` on ["MyResource"]

Migration Guide

The ReportExecutionOrderAmbiguities resource is now ExecutionOrderAmbiguities: you can adjust the level of the enum to match your preferred strictness level.

The concept of "ambiguity sets" has been simplified away: simply use .label(SharedLabel).ambiguous_with(SharedLabel) with a standard SystemLabel instead.

Status

Rebasing this is proving to be a disaster; I'm going to remake this, ideally in a series of small PRs.

Future work

If you think any of these are dealbreakers, do let me know. For now though, this PR is already way too large.

solve Detecting system order ambiguities requires a specific world #4364
solve Ambiguity reporting does not account for effects of Without query filters, leading to false positives #4381
report stage name (requires piping some metadata through a lot of plumbing), or yeet stages
remove all internal execution order ambiguities, the example to check for these, and the ReportInternal enum variant (Tracking issue: eliminate or explicitly silence all Bevy-internal execution order ambiguities #4377)

alice-i-cecile · 2022-03-23T05:41:59Z

Comments

There's a bit of a mess when trying to report all of the ambiguities for each stage, as we can't collect exclusive and non-exclusive systems together. Once Add &mut World as a system param and make .exclusive_system() optional #4166 lands, that should be fixable.
Because these ambiguities are reported per stage, I really want it to report which stage it's coming from. Unfortunately, I couldn't see a good way to do so: this information is erased at the SystemStage level. I'm considering piping in the stage name somehow, but this PR is already too big.

EDIT: I took a look, and it's not going to be nice. We need this information at SystemStage, but those are constructed from a Box dyn ParallelExecutor, and adding the name at that step breaks the trait object. Officially punted.

I'm not thrilled with the way that the ambiguities are disabled per plugin still: it feels very manual for something that should be a setting. Let me see what I can do without a full refactor of how plugins work.

maniwani

Looks good. Thanks for following up on my request in the original PR. I also like that the resource is enabled and set to minimal by default.

Just a small nit about wording.

crates/bevy_ecs/src/schedule/stage.rs

mockersf · 2022-03-23T09:59:59Z

Would it be interesting for CI purposes to have a way to exit the app with the number of conflicts as the status code? Or at least not 0 if there are conflicts

alice-i-cecile · 2022-03-23T15:42:52Z

Would it be interesting for CI purposes to have a way to exit the app with the number of conflicts as the status code? Or at least not 0 if there are conflicts

IMO the way to do this is to allow users to forbid ambiguities, at both a plugin and app level. This is fundamentally what we need for determinism. I think that's very much worth pursuing, but out of scope for this.

crates/bevy_ecs/src/schedule/ambiguity_detection.rs

crates/bevy_ecs/src/schedule/system_descriptor.rs

hymm · 2022-03-28T18:28:51Z

Is there a way to un-ignore the internal plugins?

alice-i-cecile · 2022-03-28T19:31:06Z

Is there a way to un-ignore the internal plugins?

Yes. Change the ignore_crates field of ReportExecutionOrderAmbiguties.

That said, this whole design is eh... I'm going to see if I can come up with a more reasonable design for this.

alice-i-cecile · 2022-03-28T20:46:24Z

That said, this whole design [for ignoring crates] is eh... I'm going to see if I can come up with a more reasonable design for this.

I took a pass at this, and it's not going to be triviak. Current problems:

This scatters the execution order ignoring all over bevy, with no rhyme or reason.
It's very hard to discover that you can do this.
We have to store two fields in ReportExecutionOrderAmbiguities, and rely on a overwrought builder struct.

Blockers:

We can't reasonably fix all of the internal ambiguities in this PR, for merge-ability reasons.
Simply adding the crates to the ignored_crates field doesn't stop ambiguities between them
We don't want internally ignored crates to also ignore ambiguities with user systems.
We can't reasonably have a "ignore conflicts on this component / resource" config without a Resource trait.

I think I can make this work though, and I think that hard-coding a list internally is the least bad solution.

alice-i-cecile · 2022-03-30T17:15:43Z

crates/bevy_ecs/src/schedule/stage.rs

@@ -1574,393 +1415,6 @@ mod tests {
        stage.run(&mut world);
    }

-    #[test]


This test is very fragile and hard to use due to the elaborate "label" reporting strategy.

I've done my best to replace the functionality over in the tests in ambiguity_detection.rs.

crates/bevy_ecs/src/schedule/ambiguity_detection.rs

alice-i-cecile · 2022-03-30T17:19:31Z

crates/bevy_ecs/src/schedule/stage.rs

-            self.executor.rebuild_cached_data(&self.parallel);
-            self.executor_modified = false;
-        }
+        self.initialize(world);


This functionality is useful to the public, so I refactored it out into its own method.

In the long-term I'd prefer a type-safe pattern for this sort of initialized vs uninitailized state, but that's way out of scope.

alice-i-cecile · 2022-03-30T17:25:38Z

crates/bevy_ecs/src/schedule/ambiguity_detection.rs

+        debug_assert!(!self.systems_modified);
+
+        // TODO: remove all internal ambiguities and remove this logic
+        let ignored_crates = if report_level != ReportExecutionOrderAmbiguities::ReportInternal {


The alternative strategy, of making this a configurable field on a per plugin basis or otherwise enabling this resulted in a much more complex, less ergonomic API.

The hard-coded list still existed, it was just scattered across a dozen different files.

alice-i-cecile · 2022-03-30T22:20:48Z

crates/bevy_ecs/src/schedule/ambiguity_detection.rs

+}
+
+/// Collapses a name returned by std::any::type_name to remove its module path
+fn format_type_name(raw_name: &str) -> String {


This could probably be done with a single gnarly regex, but I'm not actually sure that would be more readable or maintainable.

There's a function TypeRegistration::get_short_name that does something very similar to this function. Not sure if it matches exactly.

This is an exact match. I've refactored this out into bevy_utils and reused it.

Thanks!

hymm · 2022-03-30T22:50:42Z

Since you're using println! is this going to try to print to the console in production if people forget to turn this off?

alice-i-cecile · 2022-03-30T22:58:05Z

Since you're using println! is this going to try to print to the console in production if people forget to turn this off?

Probably. I'd like to use info!() or warn!() but their logging output is very noisy: #4299 (comment)

alice-i-cecile · 2022-03-31T17:21:28Z

@hymm @maniwani @MrGVSV I managed to swap over to the tracing warn and error macros: it's much less noisy now that I condensed the output for each stage. I think this is ready for final review now: it's in a good place, and I would really like to avoid making this PR larger.

…tils` (bevyengine#5174) # Summary This method strips a long type name like `bevy::render::camera::PerspectiveCameraBundle` down into the bare type name (`PerspectiveCameraBundle`). This is generally useful utility method, needed by bevyengine#4299 and bevyengine#5121. As a result: - This method was moved to `bevy_utils` for easier reuse. - The legibility and robustness of this method has been significantly improved. - Harder test cases have been added. This change was split out of bevyengine#4299 to unblock it and make merging / reviewing the rest of those changes easier. ## Changelog - added `bevy_utils::get_short_name`, which strips the path from a type name for convenient display. - removed the `TypeRegistry::get_short_name` method. Use the function in `bevy_utils` instead.

alice-i-cecile · 2022-09-03T19:50:48Z

Going to carve this up for easier reviewing and less rebasing hell. Based on the original PR description, let's carve this up as follows.

Foundational:

Provide an "X unresolved ambiguities detected" message that runs by default. Rather than toggling ambiguity detection on/off, have five states: Allow / WarnMinimal / WarnVerbose / Deny / Forbid. This would provide discoverability that system ambiguities are a thing and let developers see when the change that they just made added / removed some ambiguities at a glance.
Solve all remaining Bevy-internal ambiguities.

Disjoint improvements:

Number the reported ambiguities, to make them easier to discuss in a team.
Display function signatures of conflicting systems.
Report ambiguities where all pairwise combinations of systems conflict on the same data as a group.
Create a simple .ignore_all_ambiguities() method that causes a system to be ignored completely in the ambiguity checker. This would only be useful for inconsequential systems like particle effect creation.
Replace ambiguity sets with a simple .ambiguous_with(system_label) method, which allows your system to be ambiguous with the provided label (or system, via [Merged by Bors] - Auto-label function systems with SystemTypeIdLabel #4224).
Explain which component(s) / resource(s) the systems are conflicting on.
Provide an way to ignore/filter crates when using ambiguity checker.
Use short version of system and type names, rather than full path (generally, this is just noise and makes the output much harder to read).
Add an example of using ambiguity reporting

Incremental:

Improve docs.
Use tracing's warn and error macros, rather than println.

Yeet (fixed by 2 of foundational work):

By default, ambiguity checker should ignore internal bevy crates.
Add a WarnInternal reporting level, and included an example to the tools folder that reports all of the Bevy-internal ambiguities. Should be helpful for developers until we quash the last few.

# Objective Ambiguity sets are used to ignore system order ambiguities between groups of systems. However, they are not very useful: they are clunky, poorly integrated, and generally hampered by the difficulty using (or discovering) the ambiguity detector. As a first step to the work in #4299, we're removing them. ## Migration Guide Ambiguity sets have been removed.

# Objective This code is very disjoint, and the `stage.rs` file that it's in is already very long. All I've done is move the code and clean up the compiler errors that result. Followup to #5916, split out from #4299.

# Objective Ambiguity sets are used to ignore system order ambiguities between groups of systems. However, they are not very useful: they are clunky, poorly integrated, and generally hampered by the difficulty using (or discovering) the ambiguity detector. As a first step to the work in bevyengine#4299, we're removing them. ## Migration Guide Ambiguity sets have been removed.

# Objective This code is very disjoint, and the `stage.rs` file that it's in is already very long. All I've done is move the code and clean up the compiler errors that result. Followup to bevyengine#5916, split out from bevyengine#4299.

@alice-i-cecile

# Objective - Add unit tests for ambiguity detection reporting. - Incremental implementation of #4299. ## Solution - Refactor ambiguity detection internals to make it testable. As a bonus, this should make it easier to extend in the future. ## Notes * This code was copy-pasted from #4299 and modified. Credit goes to @alice-i-cecile and @afonsolage, though I'm not sure who wrote what at this point.

@alice-i-cecile

# Objective - Add unit tests for ambiguity detection reporting. - Incremental implementation of #4299. ## Solution - Refactor ambiguity detection internals to make it testable. As a bonus, this should make it easier to extend in the future. ## Notes * This code was copy-pasted from #4299 and modified. Credit goes to @alice-i-cecile and @afonsolage, though I'm not sure who wrote what at this point.

# Background Incremental implementation of #4299. The code is heavily borrowed from that PR. # Objective The execution order ambiguity checker often emits false positives, since bevy is not aware of invariants upheld by the user. ## Solution Title --- ## Changelog + Added methods `SystemDescriptor::ignore_all_ambiguities` and `::ambiguous_with`. These allow you to silence warnings for specific system-order ambiguities. ## Migration Guide ***Note for maintainers**: This should replace the migration guide for #5916* Ambiguity sets have been replaced with a simpler API. ```rust // These systems technically conflict, but we don't care which order they run in. fn jump_on_click(mouse: Res<Input<MouseButton>>, mut transforms: Query<&mut Transform>) { ... } fn jump_on_spacebar(keys: Res<Input<KeyCode>>, mut transforms: Query<&mut Transform>) { ... } // // Before #[derive(AmbiguitySetLabel)] struct JumpSystems; app .add_system(jump_on_click.in_ambiguity_set(JumpSystems)) .add_system(jump_on_spacebar.in_ambiguity_set(JumpSystems)); // // After app .add_system(jump_on_click.ambiguous_with(jump_on_spacebar)) .add_system(jump_on_spacebar); ```

@alice-i-cecile

# Objective - Add unit tests for ambiguity detection reporting. - Incremental implementation of bevyengine#4299. ## Solution - Refactor ambiguity detection internals to make it testable. As a bonus, this should make it easier to extend in the future. ## Notes * This code was copy-pasted from bevyengine#4299 and modified. Credit goes to @alice-i-cecile and @afonsolage, though I'm not sure who wrote what at this point.

…#6158) # Background Incremental implementation of bevyengine#4299. The code is heavily borrowed from that PR. # Objective The execution order ambiguity checker often emits false positives, since bevy is not aware of invariants upheld by the user. ## Solution Title --- ## Changelog + Added methods `SystemDescriptor::ignore_all_ambiguities` and `::ambiguous_with`. These allow you to silence warnings for specific system-order ambiguities. ## Migration Guide ***Note for maintainers**: This should replace the migration guide for bevyengine#5916* Ambiguity sets have been replaced with a simpler API. ```rust // These systems technically conflict, but we don't care which order they run in. fn jump_on_click(mouse: Res<Input<MouseButton>>, mut transforms: Query<&mut Transform>) { ... } fn jump_on_spacebar(keys: Res<Input<KeyCode>>, mut transforms: Query<&mut Transform>) { ... } // // Before #[derive(AmbiguitySetLabel)] struct JumpSystems; app .add_system(jump_on_click.in_ambiguity_set(JumpSystems)) .add_system(jump_on_spacebar.in_ambiguity_set(JumpSystems)); // // After app .add_system(jump_on_click.ambiguous_with(jump_on_spacebar)) .add_system(jump_on_spacebar); ```

…tils` (bevyengine#5174) # Summary This method strips a long type name like `bevy::render::camera::PerspectiveCameraBundle` down into the bare type name (`PerspectiveCameraBundle`). This is generally useful utility method, needed by bevyengine#4299 and bevyengine#5121. As a result: - This method was moved to `bevy_utils` for easier reuse. - The legibility and robustness of this method has been significantly improved. - Harder test cases have been added. This change was split out of bevyengine#4299 to unblock it and make merging / reviewing the rest of those changes easier. ## Changelog - added `bevy_utils::get_short_name`, which strips the path from a type name for convenient display. - removed the `TypeRegistry::get_short_name` method. Use the function in `bevy_utils` instead.

# Objective Ambiguity sets are used to ignore system order ambiguities between groups of systems. However, they are not very useful: they are clunky, poorly integrated, and generally hampered by the difficulty using (or discovering) the ambiguity detector. As a first step to the work in bevyengine#4299, we're removing them. ## Migration Guide Ambiguity sets have been removed.

# Objective This code is very disjoint, and the `stage.rs` file that it's in is already very long. All I've done is move the code and clean up the compiler errors that result. Followup to bevyengine#5916, split out from bevyengine#4299.

@alice-i-cecile

# Objective - Add unit tests for ambiguity detection reporting. - Incremental implementation of bevyengine#4299. ## Solution - Refactor ambiguity detection internals to make it testable. As a bonus, this should make it easier to extend in the future. ## Notes * This code was copy-pasted from bevyengine#4299 and modified. Credit goes to @alice-i-cecile and @afonsolage, though I'm not sure who wrote what at this point.

…#6158) # Background Incremental implementation of bevyengine#4299. The code is heavily borrowed from that PR. # Objective The execution order ambiguity checker often emits false positives, since bevy is not aware of invariants upheld by the user. ## Solution Title --- ## Changelog + Added methods `SystemDescriptor::ignore_all_ambiguities` and `::ambiguous_with`. These allow you to silence warnings for specific system-order ambiguities. ## Migration Guide ***Note for maintainers**: This should replace the migration guide for bevyengine#5916* Ambiguity sets have been replaced with a simpler API. ```rust // These systems technically conflict, but we don't care which order they run in. fn jump_on_click(mouse: Res<Input<MouseButton>>, mut transforms: Query<&mut Transform>) { ... } fn jump_on_spacebar(keys: Res<Input<KeyCode>>, mut transforms: Query<&mut Transform>) { ... } // // Before #[derive(AmbiguitySetLabel)] struct JumpSystems; app .add_system(jump_on_click.in_ambiguity_set(JumpSystems)) .add_system(jump_on_spacebar.in_ambiguity_set(JumpSystems)); // // After app .add_system(jump_on_click.ambiguous_with(jump_on_spacebar)) .add_system(jump_on_spacebar); ```

…tils` (bevyengine#5174) # Summary This method strips a long type name like `bevy::render::camera::PerspectiveCameraBundle` down into the bare type name (`PerspectiveCameraBundle`). This is generally useful utility method, needed by bevyengine#4299 and bevyengine#5121. As a result: - This method was moved to `bevy_utils` for easier reuse. - The legibility and robustness of this method has been significantly improved. - Harder test cases have been added. This change was split out of bevyengine#4299 to unblock it and make merging / reviewing the rest of those changes easier. ## Changelog - added `bevy_utils::get_short_name`, which strips the path from a type name for convenient display. - removed the `TypeRegistry::get_short_name` method. Use the function in `bevy_utils` instead.

# Objective Ambiguity sets are used to ignore system order ambiguities between groups of systems. However, they are not very useful: they are clunky, poorly integrated, and generally hampered by the difficulty using (or discovering) the ambiguity detector. As a first step to the work in bevyengine#4299, we're removing them. ## Migration Guide Ambiguity sets have been removed.

# Objective This code is very disjoint, and the `stage.rs` file that it's in is already very long. All I've done is move the code and clean up the compiler errors that result. Followup to bevyengine#5916, split out from bevyengine#4299.

@alice-i-cecile

# Objective - Add unit tests for ambiguity detection reporting. - Incremental implementation of bevyengine#4299. ## Solution - Refactor ambiguity detection internals to make it testable. As a bonus, this should make it easier to extend in the future. ## Notes * This code was copy-pasted from bevyengine#4299 and modified. Credit goes to @alice-i-cecile and @afonsolage, though I'm not sure who wrote what at this point.

…#6158) # Background Incremental implementation of bevyengine#4299. The code is heavily borrowed from that PR. # Objective The execution order ambiguity checker often emits false positives, since bevy is not aware of invariants upheld by the user. ## Solution Title --- ## Changelog + Added methods `SystemDescriptor::ignore_all_ambiguities` and `::ambiguous_with`. These allow you to silence warnings for specific system-order ambiguities. ## Migration Guide ***Note for maintainers**: This should replace the migration guide for bevyengine#5916* Ambiguity sets have been replaced with a simpler API. ```rust // These systems technically conflict, but we don't care which order they run in. fn jump_on_click(mouse: Res<Input<MouseButton>>, mut transforms: Query<&mut Transform>) { ... } fn jump_on_spacebar(keys: Res<Input<KeyCode>>, mut transforms: Query<&mut Transform>) { ... } // // Before #[derive(AmbiguitySetLabel)] struct JumpSystems; app .add_system(jump_on_click.in_ambiguity_set(JumpSystems)) .add_system(jump_on_spacebar.in_ambiguity_set(JumpSystems)); // // After app .add_system(jump_on_click.ambiguous_with(jump_on_spacebar)) .add_system(jump_on_spacebar); ```

# Objective - This test was mysteriously commented out ## Solution - Re-enable it - Also done in bevyengine#4299, but this is better as its own PR.

github-actions bot added the S-Needs-Triage This issue needs to be labelled label Mar 23, 2022

alice-i-cecile added A-ECS Entities, components, systems, and events C-Usability A targeted quality-of-life change that makes Bevy easier to use and removed S-Needs-Triage This issue needs to be labelled labels Mar 23, 2022

alice-i-cecile mentioned this pull request Mar 23, 2022

Simple improvements to ambiguity reporting clarity #2766

Closed

11 tasks

maniwani suggested changes Mar 23, 2022

View reviewed changes

crates/bevy_ecs/src/schedule/stage.rs Outdated Show resolved Hide resolved

MrGVSV reviewed Mar 28, 2022

View reviewed changes

alice-i-cecile force-pushed the improvements-to-ambiguity-reporting branch from 1705039 to c01cd76 Compare March 28, 2022 18:08

alice-i-cecile mentioned this pull request Mar 30, 2022

Detecting system order ambiguities requires a specific world #4364

Open

alice-i-cecile force-pushed the improvements-to-ambiguity-reporting branch from d841f38 to 870f3e8 Compare March 30, 2022 15:46

alice-i-cecile marked this pull request as draft March 30, 2022 17:06

alice-i-cecile commented Mar 30, 2022

View reviewed changes

crates/bevy_ecs/src/schedule/ambiguity_detection.rs Outdated Show resolved Hide resolved

alice-i-cecile commented Mar 30, 2022

View reviewed changes

alice-i-cecile marked this pull request as ready for review March 30, 2022 17:22

alice-i-cecile commented Mar 30, 2022

View reviewed changes

alice-i-cecile added the M-Needs-Migration-Guide A breaking change to Bevy's public API that needs to be noted in a migration guide label Mar 30, 2022

alice-i-cecile force-pushed the improvements-to-ambiguity-reporting branch 2 times, most recently from 79466fd to 1720cf5 Compare March 31, 2022 05:11

alice-i-cecile mentioned this pull request Mar 31, 2022

Tracking issue: eliminate or explicitly silence all Bevy-internal execution order ambiguities #4377

Closed

11 tasks

alice-i-cecile mentioned this pull request Sep 8, 2022

[Merged by Bors] - Remove ambiguity sets #5916

Closed

alice-i-cecile closed this Sep 8, 2022

alice-i-cecile mentioned this pull request Sep 8, 2022

[Merged by Bors] - Move ambiguity detection into its own file #5918

Closed

JoJoJet mentioned this pull request Sep 21, 2022

[Merged by Bors] - Add ambiguity detection tests #6053

Closed

JoJoJet mentioned this pull request Sep 23, 2022

Improve formatting for execution order ambiguity reports #6071

Closed

JoJoJet mentioned this pull request Oct 3, 2022

[Merged by Bors] - Add methods for silencing system-order ambiguity warnings #6158

Closed

alice-i-cecile mentioned this pull request Jan 27, 2023

Deny internal execution order ambiguities in CI #7386

Open

4 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Improvements to execution order ambiguity reporting #4299

Improvements to execution order ambiguity reporting #4299

alice-i-cecile commented Mar 23, 2022 •

edited

Loading

alice-i-cecile commented Mar 23, 2022 •

edited

Loading

maniwani left a comment

mockersf commented Mar 23, 2022

alice-i-cecile commented Mar 23, 2022

hymm commented Mar 28, 2022

alice-i-cecile commented Mar 28, 2022 •

edited

Loading

alice-i-cecile commented Mar 28, 2022

alice-i-cecile Mar 30, 2022

alice-i-cecile Mar 30, 2022

alice-i-cecile Mar 30, 2022

alice-i-cecile Mar 30, 2022

hymm Apr 4, 2022

alice-i-cecile Apr 4, 2022 •

edited

Loading

hymm commented Mar 30, 2022 •

edited

Loading

alice-i-cecile commented Mar 30, 2022

alice-i-cecile commented Mar 31, 2022 •

edited

Loading

alice-i-cecile commented Sep 3, 2022

Improvements to execution order ambiguity reporting #4299

Improvements to execution order ambiguity reporting #4299

Conversation

alice-i-cecile commented Mar 23, 2022 • edited Loading

Context

Objective

Solution

Changelog

Migration Guide

Status

Future work

alice-i-cecile commented Mar 23, 2022 • edited Loading

Comments

maniwani left a comment

Choose a reason for hiding this comment

mockersf commented Mar 23, 2022

alice-i-cecile commented Mar 23, 2022

hymm commented Mar 28, 2022

alice-i-cecile commented Mar 28, 2022 • edited Loading

alice-i-cecile commented Mar 28, 2022

alice-i-cecile Mar 30, 2022

Choose a reason for hiding this comment

alice-i-cecile Mar 30, 2022

Choose a reason for hiding this comment

alice-i-cecile Mar 30, 2022

Choose a reason for hiding this comment

alice-i-cecile Mar 30, 2022

Choose a reason for hiding this comment

hymm Apr 4, 2022

Choose a reason for hiding this comment

alice-i-cecile Apr 4, 2022 • edited Loading

Choose a reason for hiding this comment

hymm commented Mar 30, 2022 • edited Loading

alice-i-cecile commented Mar 30, 2022

alice-i-cecile commented Mar 31, 2022 • edited Loading

alice-i-cecile commented Sep 3, 2022

alice-i-cecile commented Mar 23, 2022 •

edited

Loading

alice-i-cecile commented Mar 23, 2022 •

edited

Loading

alice-i-cecile commented Mar 28, 2022 •

edited

Loading

alice-i-cecile Apr 4, 2022 •

edited

Loading

hymm commented Mar 30, 2022 •

edited

Loading

alice-i-cecile commented Mar 31, 2022 •

edited

Loading