Feature gating subsystems via `#[cfg]` #41

skunert · 2023-03-27T11:47:00Z

In this PR I introduce guarding of subsystems via features.
Supported syntax:

#[orchestra(signal=Signal, event=ExternalEvent, error=SubsystemError, gen=AllMessages)]
struct MyOverseer<T, U, V, W> {
	#[cfg(feature = "feature1")]
	#[subsystem(consumes: Subsystem1Message, sends: [Subsystem2Message])]
	subsystem1: Sub1,

	#[subsystem(consumes: Subsystem2Message, sends: [Subsystem1Message])]
	subsystem2: Sub2,
}

Basically this allows re-use of one orchestra in scenarios where it is not needed to run all subsystems. The #cfg attribute macro currently supports any, all, not and feature = "something".

Limitations

Feature unification. The current implementation is not very useful when you have a large workspace, and different crates depend on the defined orchestra with different features enabled.
Performance depends on the number of unique cfg expressions defined in the crate. With the current design of the orchestra builder, I have to build distinct feature combinations for the builder. This scales with O(2^n) where n is the number of distinct feature expressions. I tested a bit and impact is starting to show at around 7 different feature expressions.

drahnr · 2023-03-27T11:52:30Z

README.md

@@ -15,6 +15,7 @@ declarative.
        #[subsystem(MsgA, sends: [MsgB])]
        sub_a: AwesomeSubSysA,

+        #[cfg(any(feature = "feature1", feature = "feature2"))]


orchestra/proc-macro/src/impl_builder.rs

Co-authored-by: Bernhard Schuster <[email protected]>

orchestra/proc-macro/src/parse/parse_orchestra_struct.rs

orchestra/proc-macro/src/parse/parse_cfg.rs

drahnr · 2023-03-27T14:32:45Z

orchestra/proc-macro/src/parse/parse_cfg.rs

+		assert_eq!("any (not (feature = \"no\") , any (feature = \"any2\" , feature = \"any1\") , all (feature = \"f2\" , feature = \"f1\" , feature = \"f3\"))"
+				   , to_parse.to_token_stream().to_string());
+	}
+}


Very very nice.

drahnr

A few small nits, generally looks very good!

Q: do we want to allow arbitrary #[] macros eventually? I.e. copying derive over to the generated struct only and keeping any other ones on all items. But that's for another time I think.

skunert · 2023-03-28T09:15:37Z

Q: do we want to allow arbitrary #[] macros eventually? I.e. copying derive over to the generated struct only and keeping any other ones on all items. But that's for another time I think.

Not sure I understand, how could this be used?

skunert added 25 commits March 13, 2023 13:32

Prepare for feature guarding of subsystems

eda1983

Guard more occurences

0c94f11

Improve

24d8962

Remove old implementation

527a8bb

Prepare new version

8110935

Hacky initial version

f525b37

First working version

9776941

Remove duplicated code

fc9c397

Deduplicate more code

9efdffc

Keep subsystems in definition order

6ace355

Allow arbitrary feature guards

81ba2ef

Remove trailing commas where not necessary

331c269

Improve naming

eae56ac

Clean up abstractions

940f9e0

First version of cfg parsing

5abe55a

Improve parsing

ced61f1

Implement ToTokens

d68df45

Simplify code

abb71bf

Remove unnecessary clones

d53d131

Improve test naming

a975f85

Improve naming

5616259

Use unique instead of dedup

759813a

Add README entry

13bd484

Merge branch 'master' into skunert/feature-guarded-subsystems

b79e21d

Unify naming, remove unwanted changes

d083dd7

skunert requested a review from drahnr March 27, 2023 11:47