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 |
bgw
changed the title
TaskOutput::Return values in the turbo-tasks macrosTaskOutput::Return values in macros
|
Some unit tests used this expansion.
bgw
changed the title
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 -->
4 tasks
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