Resharper-unity: Suggestions for static code analysis for ECS

Created on 20 Sep 2019  路  1Comment  路  Source: JetBrains/resharper-unity

I have some ideas for code ECS analysis that ReSharper may support.
-Native Containers disposing
-Checks if JobHandle is passed to CommandBufferSystem using AddJobHandleForProducer(handle)

Most helpful comment

Agreed, ECS has a number of easy pitfalls which some static analysis would really help on. Alongside what you have suggested, I would also suggest:

  • In IJobForEach based jobs, suggest ReadOnly and WriteOnly attributes as appropriate for components.
  • In IJobForEach based jobs, suggest moving components not read from or written to a RequireComponentTag attribute (not using it or ReadOnly is an error for completely empty components).
  • Show an error if a native container or component has a ReadOnly attribute and writes to the container/component. Likewise for WriteOnly and reading.
  • Warn if a job has a native container field marked as readonly and then the writes to the container.
  • Show an error if ComponentDataFromEntity is used to read/write an empty component (Exists() is OK, however).
  • Warn about JobHandles that are ignored.
  • Show errors when not using concurrent native collections or ParallelWriters in parallel jobs.
  • Show errors when a NativeList is passed to a job as a NativeArray without using AsDeferredJobArray() where it has been potentially written to by another job.
  • Show an error when an IJobParallelForDefer based job is scheduled with a NativeList that isn't passed into the job.
  • Show a warning when a ComponentDataFromEntity type is marked as ReadOnly in a job, but the GetComponentDataFromEntity call doesn't give the isReadOnly argument true.
  • Warn about using incorrect Allocators (e.g: using Allocator.Persistent for a native collection defined in a using statement, and so disposed of in the Temp timeframe).

>All comments

Agreed, ECS has a number of easy pitfalls which some static analysis would really help on. Alongside what you have suggested, I would also suggest:

  • In IJobForEach based jobs, suggest ReadOnly and WriteOnly attributes as appropriate for components.
  • In IJobForEach based jobs, suggest moving components not read from or written to a RequireComponentTag attribute (not using it or ReadOnly is an error for completely empty components).
  • Show an error if a native container or component has a ReadOnly attribute and writes to the container/component. Likewise for WriteOnly and reading.
  • Warn if a job has a native container field marked as readonly and then the writes to the container.
  • Show an error if ComponentDataFromEntity is used to read/write an empty component (Exists() is OK, however).
  • Warn about JobHandles that are ignored.
  • Show errors when not using concurrent native collections or ParallelWriters in parallel jobs.
  • Show errors when a NativeList is passed to a job as a NativeArray without using AsDeferredJobArray() where it has been potentially written to by another job.
  • Show an error when an IJobParallelForDefer based job is scheduled with a NativeList that isn't passed into the job.
  • Show a warning when a ComponentDataFromEntity type is marked as ReadOnly in a job, but the GetComponentDataFromEntity call doesn't give the isReadOnly argument true.
  • Warn about using incorrect Allocators (e.g: using Allocator.Persistent for a native collection defined in a using statement, and so disposed of in the Temp timeframe).
Was this page helpful?
0 / 5 - 0 ratings

Related issues

justinlueders picture justinlueders  路  3Comments

harryr0se picture harryr0se  路  5Comments

JashanChittesh picture JashanChittesh  路  3Comments

citizenmatt picture citizenmatt  路  4Comments

RealMSHB picture RealMSHB  路  3Comments