turbo-tasks: Expand <T as TaskOutput>::Return values in macros
#8096
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Previously, we'd return types like: ``` <Vc<AssetIdent> as TaskOutput>::Return ``` which is equivalent to the much simpler: ``` Vc<AssetIdent> ``` It's nice because it's easier to implement in the macros, and it's more correct, because it uses the type system to verify the type of `Vc` and `Result` are what we expect. However, it makes the rustdoc output hard to read. This attempts to the expansion of `TaskOutput::Return` inside the macro to generate more readable documentation, at the cost of some correctness.
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
6 Ignored Deployments
|
|
This stack of pull requests is managed by Graphite. Learn more about stacking. |
🟢 Turbopack Benchmark CI successful 🟢Thanks |
|
✅ This change can build |
TaskOutput::Return values in the turbo-tasks macrosTaskOutput::Return values in macros
|
Some unit tests used this expansion.
TaskOutput::Return values in macros<T as TaskOutput>::Return values in macros
sokra
approved these changes
May 7, 2024
sokra
added a commit
to vercel/next.js
that referenced
this pull request
May 8, 2024
* vercel/turborepo#8073 <!-- OJ Kwon - feat(webpack-loaders): support dummy span interface --> * vercel/turborepo#8083 <!-- OJ Kwon - fix(webpack): print resource, project path when relative calc fails --> * vercel/turborepo#8094 <!-- Tim Neutkens - Implement bindings for Turbopack trace server --> * vercel/turborepo#8061 <!-- Tobias Koppers - reduce memory usage in analyser --> * vercel/turborepo#8077 <!-- Alexander Lyon - Remove async-trait from a few crates --> * vercel/turborepo#8102 <!-- Tobias Koppers - fix memory counting without custom allocator --> * vercel/turborepo#8096 <!-- Benjamin Woodruff - turbo-tasks: Expand `<T as TaskOutput>::Return` values in macros --> * vercel/turborepo#8105 <!-- Benjamin Woodruff - turbopack-node: Use path.join for postcss loader --> * vercel/turborepo#8099 <!-- Tim Neutkens - Replace websocket with tungstenite for turbo-trace-server --> * vercel/turborepo#8060 <!-- Donny/강동윤 - feat: Add lint for `grid-template-areas` --> * vercel/turborepo#8110 <!-- Tobias Koppers - fix lockfile -->
Neosoulink
pushed a commit
to Neosoulink/turbo
that referenced
this pull request
Jun 14, 2024
…cel#8096) Previously, we'd generate function return types like: ```rust <Vc<AssetIdent> as TaskOutput>::Return ``` which is equivalent to the much simpler: ```rust Vc<AssetIdent> ``` That approach is nice because it's easier to implement in the macros, and it's more correct, because it uses the type system to verify the type of `Vc` and `Result` are what we expect. However, it makes the rustdoc output much harder to read. This attempts to the expansion of `TaskOutput::Return` inside the macro to generate more readable documentation, at the cost of some correctness. <details> <summary><strong>Rustdoc Before</strong></summary>  </details> <details> <summary><strong>Rustdoc After</strong></summary>  </details> <details> <summary><strong>Example compilation error</strong> with an invalid return type</summary>  </details>
ForsakenHarmony
pushed a commit
to vercel/next.js
that referenced
this pull request
Jul 25, 2024
…cel/turborepo#8096) Previously, we'd generate function return types like: ```rust <Vc<AssetIdent> as TaskOutput>::Return ``` which is equivalent to the much simpler: ```rust Vc<AssetIdent> ``` That approach is nice because it's easier to implement in the macros, and it's more correct, because it uses the type system to verify the type of `Vc` and `Result` are what we expect. However, it makes the rustdoc output much harder to read. This attempts to the expansion of `TaskOutput::Return` inside the macro to generate more readable documentation, at the cost of some correctness. <details> <summary><strong>Rustdoc Before</strong></summary>  </details> <details> <summary><strong>Rustdoc After</strong></summary>  </details> <details> <summary><strong>Example compilation error</strong> with an invalid return type</summary>  </details>
ForsakenHarmony
pushed a commit
to vercel/next.js
that referenced
this pull request
Jul 29, 2024
…cel/turborepo#8096) Previously, we'd generate function return types like: ```rust <Vc<AssetIdent> as TaskOutput>::Return ``` which is equivalent to the much simpler: ```rust Vc<AssetIdent> ``` That approach is nice because it's easier to implement in the macros, and it's more correct, because it uses the type system to verify the type of `Vc` and `Result` are what we expect. However, it makes the rustdoc output much harder to read. This attempts to the expansion of `TaskOutput::Return` inside the macro to generate more readable documentation, at the cost of some correctness. <details> <summary><strong>Rustdoc Before</strong></summary>  </details> <details> <summary><strong>Rustdoc After</strong></summary>  </details> <details> <summary><strong>Example compilation error</strong> with an invalid return type</summary>  </details>
ForsakenHarmony
pushed a commit
to vercel/next.js
that referenced
this pull request
Jul 29, 2024
…cel/turborepo#8096) Previously, we'd generate function return types like: ```rust <Vc<AssetIdent> as TaskOutput>::Return ``` which is equivalent to the much simpler: ```rust Vc<AssetIdent> ``` That approach is nice because it's easier to implement in the macros, and it's more correct, because it uses the type system to verify the type of `Vc` and `Result` are what we expect. However, it makes the rustdoc output much harder to read. This attempts to the expansion of `TaskOutput::Return` inside the macro to generate more readable documentation, at the cost of some correctness. <details> <summary><strong>Rustdoc Before</strong></summary>  </details> <details> <summary><strong>Rustdoc After</strong></summary>  </details> <details> <summary><strong>Example compilation error</strong> with an invalid return type</summary>  </details>
ForsakenHarmony
pushed a commit
to vercel/next.js
that referenced
this pull request
Aug 1, 2024
…cel/turborepo#8096) Previously, we'd generate function return types like: ```rust <Vc<AssetIdent> as TaskOutput>::Return ``` which is equivalent to the much simpler: ```rust Vc<AssetIdent> ``` That approach is nice because it's easier to implement in the macros, and it's more correct, because it uses the type system to verify the type of `Vc` and `Result` are what we expect. However, it makes the rustdoc output much harder to read. This attempts to the expansion of `TaskOutput::Return` inside the macro to generate more readable documentation, at the cost of some correctness. <details> <summary><strong>Rustdoc Before</strong></summary>  </details> <details> <summary><strong>Rustdoc After</strong></summary>  </details> <details> <summary><strong>Example compilation error</strong> with an invalid return type</summary>  </details>
ForsakenHarmony
pushed a commit
to vercel/next.js
that referenced
this pull request
Aug 16, 2024
* vercel/turborepo#8073 <!-- OJ Kwon - feat(webpack-loaders): support dummy span interface --> * vercel/turborepo#8083 <!-- OJ Kwon - fix(webpack): print resource, project path when relative calc fails --> * vercel/turborepo#8094 <!-- Tim Neutkens - Implement bindings for Turbopack trace server --> * vercel/turborepo#8061 <!-- Tobias Koppers - reduce memory usage in analyser --> * vercel/turborepo#8077 <!-- Alexander Lyon - Remove async-trait from a few crates --> * vercel/turborepo#8102 <!-- Tobias Koppers - fix memory counting without custom allocator --> * vercel/turborepo#8096 <!-- Benjamin Woodruff - turbo-tasks: Expand `<T as TaskOutput>::Return` values in macros --> * vercel/turborepo#8105 <!-- Benjamin Woodruff - turbopack-node: Use path.join for postcss loader --> * vercel/turborepo#8099 <!-- Tim Neutkens - Replace websocket with tungstenite for turbo-trace-server --> * vercel/turborepo#8060 <!-- Donny/강동윤 - feat: Add lint for `grid-template-areas` --> * vercel/turborepo#8110 <!-- Tobias Koppers - fix lockfile -->
bgw
added a commit
to vercel/next.js
that referenced
this pull request
Sep 24, 2024
…edVc types as arguments (#70269) ## Why? [We want to codemod structs to use `ResolvedVc<...>` for all of their field types instead of `Vc<...>`.](https://www.notion.so/vercel/Resolved-Vcs-Vc-Lifetimes-Local-Vcs-and-Vc-Refcounts-49d666d3f9594017b5b312b87ddc5bff?pvs=4) There are many constructor-like functions (see #70133) where we must accept an argument of type `Vc<...>`, and then explicitly call `.to_resolved().await?`. However, internally `#[turbo_tasks::function]` arguments are guaranteed to be resolved by the time the function runs. So we can do a cheap conversion here. ## What Instead of needing to do: ```diff #[turbo_tasks::value_impl] impl CustomProcessEnv { #[turbo_tasks::function] - pub fn new(prior: Vc<Box<dyn ProcessEnv>>, custom: Vc<EnvMap>) -> Vc<Self> { - CustomProcessEnv { prior, custom }.cell() + pub async fn new(prior: Vc<Box<dyn ProcessEnv>>, custom: Vc<EnvMap>) -> Result<Vc<Self>> { + let prior = prior.to_resolved().await?; + let custom = custom.to_resolved().await?; + Ok(CustomProcessEnv { prior, custom }.cell()) } } ``` It should now just be possible to accept `ResolvedVc` instead. The exposed function signature will be unchanged, still accepting `Vc` arguments, and a conversion will happen internally. ```diff #[turbo_tasks::value_impl] impl CustomProcessEnv { #[turbo_tasks::function] - pub fn new(prior: Vc<Box<dyn ProcessEnv>>, custom: Vc<EnvMap>) -> Vc<Self> { + pub fn new(prior: ResolvedVc<Box<dyn ProcessEnv>>, custom: ResolvedVc<EnvMap>) ->Vc<Self> { CustomProcessEnv { prior, custom }.cell() } } ``` This should also work for arguments where `Vc` is inside of a `Vec` or `Option` (other collection types are not currently supported). This PR does not support `self` arguments. That is handled by #70367. ## How - The macro inspects the argument type and rewrites it to replace `ResolvedVc` with `Vc` to get the exposed function's signature. - The `FromTaskInput` trait does the actual conversion. ### Why do this type expansion and conversion in the macro, and not as part of [the `TaskFn` trait](https://github.com/vercel/next.js/blob/8f9c6a86177513026ab4bc4fdc3575ca1efe025c/turbopack/crates/turbo-tasks/src/task/function.rs)? Without [specialization](https://github.com/rust-lang/rfcs/blob/master/text/1210-impl-specialization.md) it's not possible to implement the `FromTaskInput` trait for all `TaskInput` types, as we'd end up with overlapping impls for `Option<T>` and `Vec<T>`. There are specialization hacks ([inherent method specialization](dtolnay/case-studies#14), [autoref-specialization, and autoderef-specialization](http://lukaskalbertodt.github.io/2019/12/05/generalized-autoref-based-specialization.html)) but those hacks are mostly for macros, not for generic code: > One thing might be worth clarifying up front: the adopted version described here does not solve *the* main limitation of autoref-based specialization, namely specializing in a generic context. For example, given `fn foo<T: Clone>()`, you cannot specialize for `T: Copy` in that function with autoref-based specialization. For these kinds of parametricity-destroying cases, “real” specialization is still required. As such, the whole autoref-based specialization technique is still mainly relevant for usage with macros. So we need the macro to determine if a type implements `FromTaskInput` or `TaskInput`. We can't do this inside of generic function. Aside from that, even though it's not as technically correct, expanding the types inside the macro results in *much* more readable types in rustdoc, which is why we do this in `expand_vc_return_type` as well, even though we could use a trait's associated type instead: vercel/turborepo#8096 ## Test Plan ``` cargo nextest r -p turbo-tasks-memory test_resolved_vc cargo nextest r -p turbo-tasks-macros-tests function ``` Modify some code to use this, and use `rust-analyzer`'s macro expansion feature (after telling RA to rebuild proc macros).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Previously, we'd generate function return types like:
which is equivalent to the much simpler:
That approach is nice because it's easier to implement in the macros, and it's more correct, because it uses the type system to verify the type of
VcandResultare what we expect. However, it makes the rustdoc output much harder to read.This attempts to the expansion of
TaskOutput::Returninside the macro to generate more readable documentation, at the cost of some correctness.Rustdoc Before
Rustdoc After
Example compilation error with an invalid return type