Prevent accidentally re-creating ResolvedVc via deref by using a depr… #47589
Annotations
11 warnings and 10 notices
ubuntu-latest pipelines will use ubuntu-24.04 soon. For more details, see https://github.com/actions/runner-images/issues/10636
|
ast-grep lint step:
turbopack/crates/turbopack-core/src/diagnostics/mod.rs#L114
Don't use a Vc directly in a struct
|
ast-grep lint step:
turbopack/crates/turbopack-core/src/source_map/mod.rs#L61
Don't use a Vc directly in a struct
|
ast-grep lint step:
turbopack/crates/turbopack-core/src/source_map/mod.rs#L95
Don't use a Vc directly in a struct
|
ast-grep lint step:
turbopack/crates/turbopack-core/src/source_map/mod.rs#L96
Don't use a Vc directly in a struct
|
ast-grep lint step:
turbopack/crates/turbopack-core/src/reference/mod.rs#L37
Don't use a Vc directly in a struct
|
ast-grep lint step:
turbopack/crates/turbopack-core/src/reference/mod.rs#L52
Don't use a Vc directly in a struct
|
ast-grep lint step:
turbopack/crates/turbopack-core/src/reference/mod.rs#L90
Don't use a Vc directly in a struct
|
ast-grep lint step:
turbopack/crates/turbopack-core/src/reference/mod.rs#L129
Don't use a Vc directly in a struct
|
ast-grep lint step:
turbopack/crates/turbopack-core/src/proxied_asset.rs#L18
Don't use a Vc directly in a struct
|
ast-grep lint step:
turbopack/crates/turbopack-core/src/proxied_asset.rs#L19
Don't use a Vc directly in a struct
|
ast-grep lint step:
turbopack/crates/turbopack-core/src/reference/mod.rs#L180
Calling `RawModule::new(*source).to_resolved().await?` in a loop could be a doing a lot of work sequentially. Consider producing an iterator of futures and using `try_join`.
|
ast-grep lint step:
turbopack/crates/turbopack-core/src/resolve/mod.rs#L1062
Calling `FileSource::new(**path).to_resolved().await?` in a loop could be a doing a lot of work sequentially. Consider producing an iterator of futures and using `try_join`.
|
ast-grep lint step:
turbopack/crates/turbopack-core/src/resolve/mod.rs#L1080
Calling `FileSource::new(**path).to_resolved().await?` in a loop could be a doing a lot of work sequentially. Consider producing an iterator of futures and using `try_join`.
|
ast-grep lint step:
turbopack/crates/turbopack-core/src/resolve/mod.rs#L2254
Calling `Request::parse(Value::new(Pattern::Constant(request)))
|
ast-grep lint step:
turbopack/crates/turbopack-core/src/rebase.rs#L55
Calling `RebasedAsset::new(*module, *self.input_dir, *self.output_dir)
|
ast-grep lint step:
turbopack/crates/turbopack-css/src/chunk/mod.rs#L270
Calling `chunk_item_key.to_resolved().await?` in a loop could be a doing a lot of work sequentially. Consider producing an iterator of futures and using `try_join`.
|
ast-grep lint step:
turbopack/crates/turbopack-css/src/chunk/mod.rs#L314
Calling `SingleItemCssChunk::new(*this.chunking_context, **item)
|
ast-grep lint step:
turbopack/crates/turbo-tasks-fs/src/embed/fs.rs#L52
Calling `path.join(entry_name.clone()).to_resolved().await?` in a loop could be a doing a lot of work sequentially. Consider producing an iterator of futures and using `try_join`.
|
ast-grep lint step:
turbopack/crates/turbopack-ecmascript/src/chunk/mod.rs#L90
Calling `chunk_item_key.to_resolved().await?` in a loop could be a doing a lot of work sequentially. Consider producing an iterator of futures and using `try_join`.
|
ast-grep lint step:
crates/next-core/src/next_shared/transforms/swc_ecma_transform_plugins.rs#L54
Calling `project_path.root().to_resolved().await?` in a loop could be a doing a lot of work sequentially. Consider producing an iterator of futures and using `try_join`.
|
Loading