-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement resolution for local Vcs #8826
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
8 Skipped Deployments
|
Warning This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
This stack of pull requests is managed by Graphite. Learn more about stacking. |
🟢 Turbopack Benchmark CI successful 🟢Thanks |
✅ This change can build |
|
b8bcdb0
to
f5e96f6
Compare
f5e96f6
to
e797645
Compare
e797645
to
c077f59
Compare
c077f59
to
aad914c
Compare
aad914c
to
4c2a735
Compare
4c2a735
to
5ca29c1
Compare
Moved to the next.js repo: vercel/next.js#68472 |
*This is a migrated PR. This was in the turbo repository before the next.js merge.* **Migrated From:** vercel/turborepo#8826 ### Description Builds on the minimal implementation of local Vcs in #68469 At some point, we need to return local Vcs or pass them to another function as an argument. However, local Vcs are only valid within the context of the current task. The solution is that we need to convert local `Vc`s to non-local `Vc`s, and the easiest way to do that is to `.resolve()` it! This PR creates the new non-local cell on the current task, re-using the SharedReference the was used for the local cell, along with it's type id information. `RawVc` lacks information about the compile-time type `T`. Even `Vc` may know the real type of `T` if the `Vc` has been downcast to `Vc<Box<dyn ...>>`. To solve for this, we perform a lookup of the `VcCellMode::raw_cell` method using the type id (I added `raw_cell` in #68467). ### Testing Instructions ``` cargo nextest r -p turbo-tasks -p turbo-tasks-memory ```
*This is a migrated PR. This was in the turbo repository before the next.js merge.* **Migrated From:** vercel/turborepo#8826 ### Description Builds on the minimal implementation of local Vcs in #68469 At some point, we need to return local Vcs or pass them to another function as an argument. However, local Vcs are only valid within the context of the current task. The solution is that we need to convert local `Vc`s to non-local `Vc`s, and the easiest way to do that is to `.resolve()` it! This PR creates the new non-local cell on the current task, re-using the SharedReference the was used for the local cell, along with it's type id information. `RawVc` lacks information about the compile-time type `T`. Even `Vc` may know the real type of `T` if the `Vc` has been downcast to `Vc<Box<dyn ...>>`. To solve for this, we perform a lookup of the `VcCellMode::raw_cell` method using the type id (I added `raw_cell` in #68467). ### Testing Instructions ``` cargo nextest r -p turbo-tasks -p turbo-tasks-memory ```
*This is a migrated PR. This was in the turbo repository before the next.js merge.* **Migrated From:** vercel/turborepo#8826 ### Description Builds on the minimal implementation of local Vcs in #68469 At some point, we need to return local Vcs or pass them to another function as an argument. However, local Vcs are only valid within the context of the current task. The solution is that we need to convert local `Vc`s to non-local `Vc`s, and the easiest way to do that is to `.resolve()` it! This PR creates the new non-local cell on the current task, re-using the SharedReference the was used for the local cell, along with it's type id information. `RawVc` lacks information about the compile-time type `T`. Even `Vc` may know the real type of `T` if the `Vc` has been downcast to `Vc<Box<dyn ...>>`. To solve for this, we perform a lookup of the `VcCellMode::raw_cell` method using the type id (I added `raw_cell` in #68467). ### Testing Instructions ``` cargo nextest r -p turbo-tasks -p turbo-tasks-memory ```
*This is a migrated PR. This was in the turbo repository before the next.js merge.* **Migrated From:** vercel/turborepo#8826 ### Description Builds on the minimal implementation of local Vcs in #68469 At some point, we need to return local Vcs or pass them to another function as an argument. However, local Vcs are only valid within the context of the current task. The solution is that we need to convert local `Vc`s to non-local `Vc`s, and the easiest way to do that is to `.resolve()` it! This PR creates the new non-local cell on the current task, re-using the SharedReference the was used for the local cell, along with it's type id information. `RawVc` lacks information about the compile-time type `T`. Even `Vc` may know the real type of `T` if the `Vc` has been downcast to `Vc<Box<dyn ...>>`. To solve for this, we perform a lookup of the `VcCellMode::raw_cell` method using the type id (I added `raw_cell` in #68467). ### Testing Instructions ``` cargo nextest r -p turbo-tasks -p turbo-tasks-memory ```
Description
Builds on the minimal implementation of local Vcs in #8780
At some point, we need to return local Vcs or pass them to another function as an argument. However, local Vcs are only valid within the context of the current task.
The solution is that we need to convert local
Vc
s to non-localVc
s, and the easiest way to do that is to.resolve()
it!This PR creates the new non-local cell on the current task, re-using the SharedReference the was used for the local cell, along with it's type id information.
RawVc
lacks information about the compile-time typeT
. EvenVc
may know the real type ofT
if theVc
has been downcast toVc<Box<dyn ...>>
. To solve for this, we perform a lookup of theVcCellMode::raw_cell
method using the type id (I addedraw_cell
in #8847).Testing Instructions