Skip to main content

gpui_macros/
gpui_macros.rs

1mod bench;
2mod derive_action;
3mod derive_app_context;
4mod derive_into_element;
5mod derive_render;
6mod derive_visual_context;
7mod property_test;
8mod register_action;
9mod styles;
10mod test;
11
12#[cfg(any(feature = "inspector", debug_assertions))]
13mod derive_inspector_reflection;
14
15use proc_macro::TokenStream;
16use syn::{DeriveInput, Ident};
17
18/// `Action` derive macro - see the trait documentation for details.
19#[proc_macro_derive(Action, attributes(action))]
20pub fn derive_action(input: TokenStream) -> TokenStream {
21    derive_action::derive_action(input)
22}
23
24/// This can be used to register an action with the GPUI runtime when you want to manually implement
25/// the `Action` trait. Typically you should use the `Action` derive macro or `actions!` macro
26/// instead.
27#[proc_macro]
28pub fn register_action(ident: TokenStream) -> TokenStream {
29    register_action::register_action(ident)
30}
31
32/// #[derive(IntoElement)] generates an `IntoElement` impl for any `RenderOnce`
33/// type, wrapping it in a `ViewElement` so it can be used as a child.
34#[proc_macro_derive(IntoElement)]
35pub fn derive_into_element(input: TokenStream) -> TokenStream {
36    derive_into_element::derive_into_element(input)
37}
38
39#[proc_macro_derive(Render)]
40#[doc(hidden)]
41pub fn derive_render(input: TokenStream) -> TokenStream {
42    derive_render::derive_render(input)
43}
44
45/// #[derive(AppContext)] is used to create a context out of anything that holds a `&mut App`
46/// Note that a `#[app]` attribute is required to identify the variable holding the &mut App.
47///
48/// Failure to add the attribute causes a compile error:
49///
50/// ```compile_fail
51/// # #[macro_use] extern crate gpui_macros;
52/// # #[macro_use] extern crate gpui;
53/// #[derive(AppContext)]
54/// struct MyContext<'a> {
55///     app: &'a mut gpui::App
56/// }
57/// ```
58#[proc_macro_derive(AppContext, attributes(app))]
59pub fn derive_app_context(input: TokenStream) -> TokenStream {
60    derive_app_context::derive_app_context(input)
61}
62
63/// #[derive(VisualContext)] is used to create a visual context out of anything that holds a `&mut Window` and
64/// implements `AppContext`
65/// Note that a `#[app]` and a `#[window]` attribute are required to identify the variables holding the &mut App,
66/// and &mut Window respectively.
67///
68/// Failure to add both attributes causes a compile error:
69///
70/// ```compile_fail
71/// # #[macro_use] extern crate gpui_macros;
72/// # #[macro_use] extern crate gpui;
73/// #[derive(VisualContext)]
74/// struct MyContext<'a, 'b> {
75///     #[app]
76///     app: &'a mut gpui::App,
77///     window: &'b mut gpui::Window
78/// }
79/// ```
80///
81/// ```compile_fail
82/// # #[macro_use] extern crate gpui_macros;
83/// # #[macro_use] extern crate gpui;
84/// #[derive(VisualContext)]
85/// struct MyContext<'a, 'b> {
86///     app: &'a mut gpui::App,
87///     #[window]
88///     window: &'b mut gpui::Window
89/// }
90/// ```
91#[proc_macro_derive(VisualContext, attributes(window, app))]
92pub fn derive_visual_context(input: TokenStream) -> TokenStream {
93    derive_visual_context::derive_visual_context(input)
94}
95
96/// Used by GPUI to generate the style helpers.
97#[proc_macro]
98#[doc(hidden)]
99pub fn style_helpers(input: TokenStream) -> TokenStream {
100    styles::style_helpers(input)
101}
102
103/// Generates methods for visibility styles.
104#[proc_macro]
105pub fn visibility_style_methods(input: TokenStream) -> TokenStream {
106    styles::visibility_style_methods(input)
107}
108
109/// Generates methods for margin styles.
110#[proc_macro]
111pub fn margin_style_methods(input: TokenStream) -> TokenStream {
112    styles::margin_style_methods(input)
113}
114
115/// Generates methods for padding styles.
116#[proc_macro]
117pub fn padding_style_methods(input: TokenStream) -> TokenStream {
118    styles::padding_style_methods(input)
119}
120
121/// Generates methods for position styles.
122#[proc_macro]
123pub fn position_style_methods(input: TokenStream) -> TokenStream {
124    styles::position_style_methods(input)
125}
126
127/// Generates methods for overflow styles.
128#[proc_macro]
129pub fn overflow_style_methods(input: TokenStream) -> TokenStream {
130    styles::overflow_style_methods(input)
131}
132
133/// Generates methods for cursor styles.
134#[proc_macro]
135pub fn cursor_style_methods(input: TokenStream) -> TokenStream {
136    styles::cursor_style_methods(input)
137}
138
139/// Generates methods for border styles.
140#[proc_macro]
141pub fn border_style_methods(input: TokenStream) -> TokenStream {
142    styles::border_style_methods(input)
143}
144
145/// Generates methods for box shadow styles.
146#[proc_macro]
147pub fn box_shadow_style_methods(input: TokenStream) -> TokenStream {
148    styles::box_shadow_style_methods(input)
149}
150
151/// `#[gpui::test]` can be used to annotate test functions that run with GPUI support.
152///
153/// It supports both synchronous and asynchronous tests, and can provide you with
154/// as many `TestAppContext` instances as you need.
155/// The output contains a `#[test]` annotation so this can be used with any existing
156/// test harness (`cargo test` or `cargo-nextest`).
157///
158/// ```
159/// #[gpui::test]
160/// async fn test_foo(mut cx: &TestAppContext) { }
161/// ```
162///
163/// In addition to passing a TestAppContext, you can also ask for a `StdRnd` instance.
164/// this will be seeded with the `SEED` environment variable and is used internally by
165/// the ForegroundExecutor and BackgroundExecutor to run tasks deterministically in tests.
166/// Using the same `StdRng` for behavior in your test will allow you to exercise a wide
167/// variety of scenarios and interleavings just by changing the seed.
168///
169/// # Arguments
170///
171/// - `#[gpui::test]` with no arguments runs once with the seed `0` or `SEED` env var if set.
172/// - `#[gpui::test(seed = 10)]` runs once with the seed `10`.
173/// - `#[gpui::test(seeds(10, 20, 30))]` runs three times with seeds `10`, `20`, and `30`.
174/// - `#[gpui::test(iterations = 5)]` runs five times, providing as seed the values in the range `0..5`.
175/// - `#[gpui::test(retries = 3)]` runs up to four times if it fails to try and make it pass.
176/// - `#[gpui::test(on_failure = "crate::test::report_failure")]` will call the specified function after the
177///   tests fail so that you can write out more detail about the failure.
178///
179/// You can combine `iterations = ...` with `seeds(...)`:
180/// - `#[gpui::test(iterations = 5, seed = 10)]` is equivalent to `#[gpui::test(seeds(0, 1, 2, 3, 4, 10))]`.
181/// - `#[gpui::test(iterations = 5, seeds(10, 20, 30)]` is equivalent to `#[gpui::test(seeds(0, 1, 2, 3, 4, 10, 20, 30))]`.
182/// - `#[gpui::test(seeds(10, 20, 30), iterations = 5]` is equivalent to `#[gpui::test(seeds(0, 1, 2, 3, 4, 10, 20, 30))]`.
183///
184/// # Environment Variables
185///
186/// - `SEED`: sets a seed for the first run
187/// - `ITERATIONS`: forces the value of the `iterations` argument
188#[proc_macro_attribute]
189pub fn test(args: TokenStream, function: TokenStream) -> TokenStream {
190    test::test(args, function)
191}
192
193/// `#[gpui::bench]` annotates a Criterion benchmark that runs with GPUI support.
194///
195/// Use `#[gpui::bench(inputs = some_iterable())]` on benchmarks that take an
196/// additional input argument; the generated benchmark uses Criterion's
197/// `bench_with_input`. `group`, `input_name`, and `sample_size` can customize
198/// the generated input benchmark group.
199///
200/// The benchmark crate must add `criterion` and `gpui_platform` (with its
201/// `test-support` feature) to its dev-dependencies and enable gpui's `bench`
202/// feature, since the generated code references all three.
203#[proc_macro_attribute]
204pub fn bench(args: TokenStream, function: TokenStream) -> TokenStream {
205    bench::bench(args, function)
206}
207
208/// A variant of `#[gpui::test]` that supports property-based testing.
209///
210/// Enable GPUI's `test-support` feature in the package's dev-dependencies before
211/// using this macro. GPUI re-exports the required proptest API, so consumers do
212/// not need to add proptest as a separate direct dependency.
213///
214/// A property test, much like a standard GPUI randomized test, allows testing
215/// claims of the form "for any possible X, Y should hold". For example:
216/// ```
217/// #[gpui::property_test]
218/// fn test_arithmetic(x: i32, y: i32) {
219///     assert!(x == y || x < y || x > y);
220/// }
221/// ```
222/// Standard GPUI randomized tests provide you with an instance of `StdRng` to
223/// generate random data in a controlled manner. Property-based tests have some
224/// advantages, however:
225/// - Shrinking - the harness also understands a notion of the "complexity" of a
226///   particular value. This allows it to find the "simplest possible value that
227///   causes the test to fail".
228/// - Ergonomics/clarity - the property-testing harness will automatically
229///   generate values, removing the need to fill the test body with generation
230///   logic.
231/// - Failure persistence - if a failing seed is identified, it is stored in a
232///   file, which can be checked in, and future runs will check these cases before
233///   future cases.
234///
235/// Property tests work best when all inputs can be generated up-front and kept
236/// in a simple data structure. Sometimes, this isn't possible - for example, if
237/// a test needs to make a random decision based on the current state of some
238/// structure. In this case, a standard GPUI randomized test may be more
239/// suitable.
240///
241/// ## Customizing random values
242///
243/// This macro is based on the
244/// [`#[proptest::property_test]`](https://docs.rs/proptest/latest/proptest/attr.property_test.html)
245/// macro, but handles some of the same GPUI-specific arguments as
246/// `#[gpui::test]`. Specifically, `&{mut,} TestAppContext` and
247/// `BackgroundExecutor` work as normal. `StdRng` arguments are **explicitly
248/// forbidden**, since they break shrinking, and are a common footgun.
249///
250/// The optional `config = ...` argument accepts a proptest `Config`; GPUI applies
251/// its deterministic scheduler seed to that configuration.
252/// Property tests may return proptest's `TestCaseResult`, including when using
253/// `prop_assert!` and related macros:
254/// ```
255/// #[gpui::property_test(
256///     config = gpui::proptest::test_runner::Config::with_cases(4),
257/// )]
258/// fn test_result(x: i32) -> gpui::proptest::test_runner::TestCaseResult {
259///     gpui::proptest::prop_assert_eq!(x, x);
260///     Ok(())
261/// }
262/// ```
263///
264/// Note: much of the following is copied from the
265/// [`#[proptest::property_test]`](https://docs.rs/proptest/latest/proptest/attr.property_test.html)
266/// macro docs.
267///
268/// Random values of type `T` are generated by a `Strategy<Value = T>` object.
269/// Some types have a canonical `Strategy` - these types also implement
270/// `Arbitrary`. Parameters to a `#[gpui::property_test]`, by default, use a
271/// type's `Arbitrary` implementation. If you'd like to provide a custom
272/// strategy, you can use `#[strategy = ...]` on the argument:
273/// ```
274/// #[gpui::property_test]
275/// fn int_test(#[strategy = 1..10] x: i32, #[strategy = "[a-zA-Z0-9]{20}"] s: String) {
276///   assert!(s.len() > (x as usize));
277/// }
278/// ```
279///
280/// For more information on writing custom `Strategy` and `Arbitrary`
281/// implementations, see [the proptest book](https://proptest-rs.github.io/proptest/intro.html)
282/// and the [`Strategy`](https://docs.rs/proptest/latest/proptest/strategy/trait.Strategy.html)
283/// trait.
284///
285/// ## Scheduler
286///
287/// Similar to `#[gpui::test]`, this macro will choose random seeds for the test
288/// scheduler. It uses `.no_shrink()` to tell proptest that all seeds are
289/// roughly equivalent in terms of "complexity". If `$SEED` is set, it will
290/// affect **ONLY** the seed passed to the scheduler. To control other values,
291/// use custom `Strategy`s.
292///
293#[proc_macro_attribute]
294pub fn property_test(args: TokenStream, function: TokenStream) -> TokenStream {
295    property_test::test(args.into(), function.into()).into()
296}
297
298/// When added to a trait, `#[derive_inspector_reflection]` generates a module which provides
299/// enumeration and lookup by name of all methods that have the shape `fn method(self) -> Self`.
300/// This is used by the inspector so that it can use the builder methods in `Styled` and
301/// `StyledExt`.
302///
303/// The generated module will have the name `<snake_case_trait_name>_reflection` and contain the
304/// following functions:
305///
306/// ```ignore
307/// pub fn methods::<T: TheTrait + 'static>() -> Vec<gpui::inspector_reflection::FunctionReflection<T>>;
308///
309/// pub fn find_method::<T: TheTrait + 'static>() -> Option<gpui::inspector_reflection::FunctionReflection<T>>;
310/// ```
311///
312/// The `invoke` method on `FunctionReflection` will run the method. `FunctionReflection` also
313/// provides the method's documentation.
314#[cfg(any(feature = "inspector", debug_assertions))]
315#[proc_macro_attribute]
316pub fn derive_inspector_reflection(_args: TokenStream, input: TokenStream) -> TokenStream {
317    derive_inspector_reflection::derive_inspector_reflection(_args, input)
318}
319
320pub(crate) fn get_simple_attribute_field(ast: &DeriveInput, name: &'static str) -> Option<Ident> {
321    match &ast.data {
322        syn::Data::Struct(data_struct) => data_struct
323            .fields
324            .iter()
325            .find(|field| field.attrs.iter().any(|attr| attr.path().is_ident(name)))
326            .map(|field| field.ident.clone().unwrap()),
327        syn::Data::Enum(_) => None,
328        syn::Data::Union(_) => None,
329    }
330}