Skip to content
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

Support turbo tasks inside of mod blocks #8530

Merged
merged 1 commit into from
Jun 24, 2024
Merged

Support turbo tasks inside of mod blocks #8530

merged 1 commit into from
Jun 24, 2024

Conversation

bgw
Copy link
Member

@bgw bgw commented Jun 18, 2024

Description

I noticed this wasn't implemented when trying to write some unit tests inside of mod tests.

The same visibility requirements apply (must be at least pub(crate)).

turbo-tasks-build is the thing that generates the register() functions that are called at the top-level lib.rs of all our crates. We must generate a register call for anything annotated with #[turbo_tasks::function].

This logic parses all of your modules when build.rs is run, following every mod foo; line in your code. You can also have an inline module with a mod foo { ... } block. The code was handling the mod foo; case, but not the mod foo { ... } case (it just wasn't ever implemented).

Testing Instructions

Tested as part of #8529

Copy link

vercel bot commented Jun 18, 2024

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
examples-nonmonorepo ✅ Ready (Inspect) Visit Preview 💬 Add feedback Jun 19, 2024 3:39pm
rust-docs ✅ Ready (Inspect) Visit Preview 💬 Add feedback Jun 19, 2024 3:39pm
8 Ignored Deployments
Name Status Preview Comments Updated (UTC)
examples-basic-web ⬜️ Ignored (Inspect) Visit Preview Jun 19, 2024 3:39pm
examples-designsystem-docs ⬜️ Ignored (Inspect) Visit Preview Jun 19, 2024 3:39pm
examples-gatsby-web ⬜️ Ignored (Inspect) Visit Preview Jun 19, 2024 3:39pm
examples-kitchensink-blog ⬜️ Ignored (Inspect) Visit Preview Jun 19, 2024 3:39pm
examples-native-web ⬜️ Ignored (Inspect) Visit Preview Jun 19, 2024 3:39pm
examples-svelte-web ⬜️ Ignored (Inspect) Visit Preview Jun 19, 2024 3:39pm
examples-tailwind-web ⬜️ Ignored (Inspect) Visit Preview Jun 19, 2024 3:39pm
examples-vite-web ⬜️ Ignored (Inspect) Visit Preview Jun 19, 2024 3:39pm

Copy link
Contributor

github-actions bot commented Jun 18, 2024

🟢 Turbopack Benchmark CI successful 🟢

Thanks

Copy link
Contributor

✅ This change can build next-swc

@bgw bgw marked this pull request as ready for review June 18, 2024 13:31
@bgw bgw requested a review from a team as a code owner June 18, 2024 13:31
Copy link
Contributor

github-actions bot commented Jun 18, 2024

⚠️ CI failed ⚠️

The following steps have failed in CI:

  • Turbopack Rust tests (mac/win, non-blocking)

See workflow summary for details

I noticed this wasn't implemented when trying to write some unit tests
inside of `mod tests`.

The same visibility requirements apply (must be at least `pub(crate)`).
Copy link
Member Author

bgw commented Jun 24, 2024

Merge activity

  • Jun 24, 2:41 PM EDT: @bgw started a stack merge that includes this pull request via Graphite.
  • Jun 24, 2:41 PM EDT: @bgw merged this pull request with Graphite.

@bgw bgw merged commit 5114ed8 into main Jun 24, 2024
56 of 58 checks passed
@bgw bgw deleted the bgw/register-mod branch June 24, 2024 18:41
bgw added a commit that referenced this pull request Jun 24, 2024
### Description

If a task is conditionally compiled, we must conditionally register it.

Noticed this when trying to write a test with `#[cfg(test)]`.

**Related:** #8530 adds support for registering tasks inside of `mod foo { ... }` blocks.

### Testing Instructions

Tested as part of #8529
timneutkens added a commit to vercel/next.js that referenced this pull request Jun 26, 2024
* vercel/turborepo#8546 <!-- Benjamin Woodruff -
Decrease default scope_stress test size, add env var config -->
* vercel/turborepo#8563 <!-- Donny/강동윤 - Update
`swc_core` to `v0.95.4` -->
* vercel/turborepo#8556 <!-- Tobias Koppers - avoid
cloning the source code -->
* vercel/turborepo#8562 <!-- Will Binns-Smith - HMR:
handle non-Latin characters in text through base64-encoded sourcemaps
-->
* vercel/turborepo#8530 <!-- Benjamin Woodruff -
Support turbo tasks inside of `mod` blocks -->
* vercel/turborepo#8542 <!-- Benjamin Woodruff -
Handle `#[cfg(...)]` attributes on turbo tasks -->
* vercel/turborepo#8529 <!-- Benjamin Woodruff -
Deduplicate persistent task get_function_name logic -->
* vercel/turborepo#8547 <!-- Benjamin Woodruff - Add
new ExitHandler API as an alternative to ExitGuard -->
* vercel/turborepo#8604 <!-- Benjamin Woodruff -
Delete unused TASK_ID_MAPPING support -->
* vercel/turborepo#8605 <!-- Benjamin Woodruff -
Remove nohash-hasher dependency -->
* vercel/turborepo#8559 <!-- Tobias Koppers - move
stateful flag into Done state -->
* vercel/turborepo#8598 <!-- Tim Neutkens - MDX
support: Ensure development transform is only used in development -->
* vercel/turborepo#8557 <!-- Tobias Koppers - reduce
size of task output struct -->
* vercel/turborepo#8558 <!-- Tobias Koppers - remove
prepared task type -->


<!-- Thanks for opening a PR! Your contribution is much appreciated.
To make sure your PR is handled as smoothly as possible we request that
you follow the checklist sections below.
Choose the right checklist for the change(s) that you're making:

## For Contributors

### Improving Documentation

- Run `pnpm prettier-fix` to fix formatting issues before opening the
PR.
- Read the Docs Contribution Guide to ensure your contribution follows
the docs guidelines:
https://nextjs.org/docs/community/contribution-guide

### Adding or Updating Examples

- The "examples guidelines" are followed from our contributing doc
https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md
- Make sure the linting passes by running `pnpm build && pnpm lint`. See
https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md

### Fixing a bug

- Related issues linked using `fixes #number`
- Tests added. See:
https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md

### Adding a feature

- Implements an existing feature request or RFC. Make sure the feature
request has been accepted for implementation before opening a PR. (A
discussion must be opened, see
https://github.com/vercel/next.js/discussions/new?category=ideas)
- Related issues/discussions are linked using `fixes #number`
- e2e tests added
(https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
- Documentation added
- Telemetry added. In case of a feature if it's used or not.
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md


## For Maintainers

- Minimal description (aim for explaining to someone not on the team to
understand the PR)
- When linking to a Slack thread, you might want to share details of the
conclusion
- Link both the Linear (Fixes NEXT-xxx) and the GitHub issues
- Add review comments if necessary to explain to the reviewer the logic
behind a change

### What?

### Why?

### How?

Closes NEXT-
Fixes #

-->
ForsakenHarmony pushed a commit to vercel/next.js that referenced this pull request Jul 25, 2024
### Description
    
 I noticed this wasn't implemented when trying to write some unit tests inside of `mod tests`.
    
 The same visibility requirements apply (must be at least `pub(crate)`).

### Testing Instructions

Tested as part of vercel/turborepo#8529
ForsakenHarmony pushed a commit to vercel/next.js that referenced this pull request Jul 25, 2024
### Description

If a task is conditionally compiled, we must conditionally register it.

Noticed this when trying to write a test with `#[cfg(test)]`.

**Related:** vercel/turborepo#8530 adds support for registering tasks inside of `mod foo { ... }` blocks.

### Testing Instructions

Tested as part of vercel/turborepo#8529
ForsakenHarmony pushed a commit to vercel/next.js that referenced this pull request Jul 29, 2024
### Description
    
 I noticed this wasn't implemented when trying to write some unit tests inside of `mod tests`.
    
 The same visibility requirements apply (must be at least `pub(crate)`).

### Testing Instructions

Tested as part of vercel/turborepo#8529
ForsakenHarmony pushed a commit to vercel/next.js that referenced this pull request Jul 29, 2024
### Description

If a task is conditionally compiled, we must conditionally register it.

Noticed this when trying to write a test with `#[cfg(test)]`.

**Related:** vercel/turborepo#8530 adds support for registering tasks inside of `mod foo { ... }` blocks.

### Testing Instructions

Tested as part of vercel/turborepo#8529
ForsakenHarmony pushed a commit to vercel/next.js that referenced this pull request Jul 29, 2024
### Description
    
 I noticed this wasn't implemented when trying to write some unit tests inside of `mod tests`.
    
 The same visibility requirements apply (must be at least `pub(crate)`).

### Testing Instructions

Tested as part of vercel/turborepo#8529
ForsakenHarmony pushed a commit to vercel/next.js that referenced this pull request Jul 29, 2024
### Description

If a task is conditionally compiled, we must conditionally register it.

Noticed this when trying to write a test with `#[cfg(test)]`.

**Related:** vercel/turborepo#8530 adds support for registering tasks inside of `mod foo { ... }` blocks.

### Testing Instructions

Tested as part of vercel/turborepo#8529
ForsakenHarmony pushed a commit to vercel/next.js that referenced this pull request Aug 1, 2024
### Description
    
 I noticed this wasn't implemented when trying to write some unit tests inside of `mod tests`.
    
 The same visibility requirements apply (must be at least `pub(crate)`).

### Testing Instructions

Tested as part of vercel/turborepo#8529
ForsakenHarmony pushed a commit to vercel/next.js that referenced this pull request Aug 1, 2024
### Description

If a task is conditionally compiled, we must conditionally register it.

Noticed this when trying to write a test with `#[cfg(test)]`.

**Related:** vercel/turborepo#8530 adds support for registering tasks inside of `mod foo { ... }` blocks.

### Testing Instructions

Tested as part of vercel/turborepo#8529
ForsakenHarmony pushed a commit to vercel/next.js that referenced this pull request Aug 16, 2024
* vercel/turborepo#8546 <!-- Benjamin Woodruff -
Decrease default scope_stress test size, add env var config -->
* vercel/turborepo#8563 <!-- Donny/강동윤 - Update
`swc_core` to `v0.95.4` -->
* vercel/turborepo#8556 <!-- Tobias Koppers - avoid
cloning the source code -->
* vercel/turborepo#8562 <!-- Will Binns-Smith - HMR:
handle non-Latin characters in text through base64-encoded sourcemaps
-->
* vercel/turborepo#8530 <!-- Benjamin Woodruff -
Support turbo tasks inside of `mod` blocks -->
* vercel/turborepo#8542 <!-- Benjamin Woodruff -
Handle `#[cfg(...)]` attributes on turbo tasks -->
* vercel/turborepo#8529 <!-- Benjamin Woodruff -
Deduplicate persistent task get_function_name logic -->
* vercel/turborepo#8547 <!-- Benjamin Woodruff - Add
new ExitHandler API as an alternative to ExitGuard -->
* vercel/turborepo#8604 <!-- Benjamin Woodruff -
Delete unused TASK_ID_MAPPING support -->
* vercel/turborepo#8605 <!-- Benjamin Woodruff -
Remove nohash-hasher dependency -->
* vercel/turborepo#8559 <!-- Tobias Koppers - move
stateful flag into Done state -->
* vercel/turborepo#8598 <!-- Tim Neutkens - MDX
support: Ensure development transform is only used in development -->
* vercel/turborepo#8557 <!-- Tobias Koppers - reduce
size of task output struct -->
* vercel/turborepo#8558 <!-- Tobias Koppers - remove
prepared task type -->


<!-- Thanks for opening a PR! Your contribution is much appreciated.
To make sure your PR is handled as smoothly as possible we request that
you follow the checklist sections below.
Choose the right checklist for the change(s) that you're making:

## For Contributors

### Improving Documentation

- Run `pnpm prettier-fix` to fix formatting issues before opening the
PR.
- Read the Docs Contribution Guide to ensure your contribution follows
the docs guidelines:
https://nextjs.org/docs/community/contribution-guide

### Adding or Updating Examples

- The "examples guidelines" are followed from our contributing doc
https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md
- Make sure the linting passes by running `pnpm build && pnpm lint`. See
https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md

### Fixing a bug

- Related issues linked using `fixes #number`
- Tests added. See:
https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md

### Adding a feature

- Implements an existing feature request or RFC. Make sure the feature
request has been accepted for implementation before opening a PR. (A
discussion must be opened, see
https://github.com/vercel/next.js/discussions/new?category=ideas)
- Related issues/discussions are linked using `fixes #number`
- e2e tests added
(https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
- Documentation added
- Telemetry added. In case of a feature if it's used or not.
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md


## For Maintainers

- Minimal description (aim for explaining to someone not on the team to
understand the PR)
- When linking to a Slack thread, you might want to share details of the
conclusion
- Link both the Linear (Fixes NEXT-xxx) and the GitHub issues
- Add review comments if necessary to explain to the reviewer the logic
behind a change

### What?

### Why?

### How?

Closes NEXT-
Fixes #

-->
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants