Sweep: write unit tests

[wwzeng1]

No description provided.

[sweep-ai]

Hey @wwzeng1,

I've started working on this issue. The plan is to first identify the modules that lack sufficient unit tests. After that, I'll write comprehensive tests for these modules, covering all functions and considering both expected and edge case behaviors. Once the tests are written, I'll update the testing documentation to include these new tests.

Give me a minute!

Cheers,
Sweep bot

Some code snippets I looked at (click to expand). If some file is missing from here, you can mention the path in the ticket description.

slinc/core/test/src/fr/hammons/slinc/FSetRuntimeSpec.scala

Lines 94 to 114 in 8e2ad0c

	trait L derives FSet:
	def test_fn(i: CInt): CInt
	assertEquals(
	FSet.instance[L].test_fn(2),
	2
	)
	test("Absolute file loading works"):
	if os == OS.Linux then
	if !Files.exists(Paths.get("/tmp/test.so")) then
	Files.copy(Paths.get("libs/test.so"), Paths.get("/tmp/test.so"))
	@NeedsFile("/tmp/test.so")
	trait L derives FSet:
	def test_fn(i: CInt): CInt
	assertEquals(
	FSet.instance[L].test_fn(2),
	2
	)

slinc/core/test/src/fr/hammons/slinc/modules/DescriptorSpec.scala

Lines 22 to 74 in 8e2ad0c

	derives Struct
	test("CUnionDescriptor.size gives the right size"):
	assertEquals(
	DescriptorOf[CUnion[(CInt, A, CFloat)]].size,
	DescriptorOf[A].size
	)
	test("CUnionDescriptor.alignment gives the right alignment"):
	assertEquals(
	DescriptorOf[CUnion[(CInt, A, CFloat)]].alignment,
	DescriptorOf[A].alignment
	)
	test("ByteDescriptor is 1 byte in size"):
	assertEquals(ByteDescriptor.size, Bytes(1))
	test("ShortDescriptor is 2 bytes in size"):
	assertEquals(ShortDescriptor.size, Bytes(2))
	test("IntDescriptor is 4 bytes in size"):
	assertEquals(IntDescriptor.size, Bytes(4))
	test("LongDescriptor is 8 bytes in size"):
	assertEquals(LongDescriptor.size, Bytes(8))
	test("FloatDescriptor is 4 bytes in size"):
	assertEquals(FloatDescriptor.size, Bytes(4))
	test("DoubleDescriptor is 8 bytes in size"):
	assertEquals(DoubleDescriptor.size, Bytes(8))
	test("StructDescriptor.alignment is the max of the member elements"):
	assertEquals(DescriptorOf[A].alignment, Bytes(8))
	test("StructDescriptor.size is a multiple of alignment"):
	assertEquals(DescriptorOf[A].size % DescriptorOf[A].alignment, Bytes(0))
	assert(
	DescriptorOf[A].size >= (DescriptorOf[CInt].size * 3 + DescriptorOf[
	CLongLong
	].size * 2)
	)
	test("SetSizeArrayDescriptor is size of inner type * num"):
	assertEquals(
	DescriptorOf[SetSizeArray[CInt, 15]].size,
	DescriptorOf[CInt].size * 15
	)
	test("SetSizeArrayDescriptor is alignment of inner type"):
	assertEquals(
	DescriptorOf[SetSizeArray[CInt, 15]].alignment,
	DescriptorOf[CInt].alignment

slinc/CONTRIBUTING.md

Lines 33 to 156 in 8e2ad0c

	### Editor
	When developing Slinc, it's suggested to use [VSCode](https://code.visualstudio.com/) along with the [Metals](https://marketplace.visualstudio.com/items?itemName=scalameta.metals) extension. Slinc is heavily dependent on compile-time programming, and VSCode+Metals works very well with this development model. One can use other editors, but it's probably mandatory to use Metals.
	Using metals, one can import the build definition from mill. If one encounters an issue with the import failing for no discernable reason, try deleting the `out` directory and trying again. There is a problem with this project and mill failing to generate bloop configurations. If one encounters errors when viewing a code base that do not resolve themselves, it's suggested to try closing VSCode, killing all Java processes, and deleting .metals, .bloop, and out. Generally, this will fix all issues.
	When developing for Slinc, choose an implementation to focus on, and choose the appropriate JDK for it. Switch with the appropriate `default` command on sdkman, kill all java processes, and afterwards open the project with VSCode. The corresponding `j` project should be having no missing definition errors after this process. Switching between JDK versions follows the same process.
	## Compiling
	The following commands compile the Slinc projecs:
	* core: `./mill core.compile`
	* j17: `./mill j17.compile`
	* j19: `./mill j19.compile`
	* runtime: `./mill runtime.compile`
	Compiling the entire project would normally be done by running `./mill _.compile`, but considering the different project have different JDK requirements, the full compilation takes the form of
	```bash
	sdk u java 17.0.4.1-tem && \
	./mill core.compile && \
	./mill core.test.compile && \
	./mill j17.compile && \
	sdk u java 19-tem && \
	./mill j19.compile && \
	#optional sdk u java 17.0.4.1-tem &&
	./mill runtime.compile
	```
	Only j17 and j19 have a hard dependency on specific JDK major versions. Core and runtime can be compiled with either java 17 or 19 as you wish.
	## Testing
	Tests exist for all portions of the project. They can be executed by running `./mill <project-name>.test`. Examples are:
	* `./mill j17.test`
	* `./mill j19.test`
	* `./mill core.test`
	* `./mill runtime.test`
	Please note that testing runtime involves doing the delicate compilation dance listed above.
	Testing code is generally stored in the `core` project under `core/test/src`. Java 17, Java 19, and runtime specific tests may exist in the future, but at the moment, all implementations use a generic testing base.
	Tests in Slinc use munit and scalacheck. One can read how to use munit with scalacheck [here](https://scalameta.org/munit/docs/integrations/scalacheck.html) and how to use scalacheck [here](https://github.com/typelevel/scalacheck/blob/main/doc/UserGuide.md).
	In order to develop a new test suite for Slinc, add the implementation to `core/test/src`. If the test suite is testing an implementation in `core` then one can define it in the normal way specified by the munit documentation. However, if it's meant to be a test of Slinc implementations, it should be defined in a generic fashion like so:
	```scala
	package fr.hammons.slinc
	import munit.ScalaCheckSuite
	trait MyTestSuite(slinc: Slinc) extends ScalaCheckSuite:
	import slinc.{*,given}
	test("myTest") {
	assertEquals(4,4)
	}
	```
	After defining this in core, add the test to `j17/test/src/fr/hammons/slinc` and `j19/test/src/fr/hammons/slinc` with the following code:
	```scala
	package fr.hammons.slinc
	class MyTestSuite17 extends MyTestSuite(Slinc17.default)
	```
	If one's test suite concerns JIT compilation, one can use `noJit` and `immediate` implementations to make one's test suites test the unjitted and jitted versions of the runtime.
	### Troubleshooting tests
	Sometimes when running a freshly written test, or testing freshly written code, one might encounter a situation where the test suite will stop testing early, or never stop running.
	Generally, the test suite will stop running early when some part of the Slinc runtime fails to initialize properly. One can easily detect if this is the case by moving some test code out of the test section into the root of the suite.
	Observe the following example:
	```scala
	trait MySuite(s: Slinc) extends ScalacheckSuite:
	import s.{*, given}
	test("myTest") {
	assertEquals(sizeOf[Int], 4.as[SizeT]
	}
	```
	should be rewritten to
	```scala
	trait MySuite(s: Slinc) extends ScalacheckSuite:
	import s.{*,given}
	sizeOf[Int]
	4.as[SizeT]
	test("myTest") {
	assertEquals(sizeOf[Int], 4.as[SizeT])
	}
	```
	This tends to force the test suite to actually reveal the exception that's breaking it, and will help one fix the issue in question.
	When a test suite continues forever, the cause is usually the same, but with regards to a propertyBased test:
	```scala
	trait MySuite(s: Slinc) extends ScalacheckSuite:
	import s.{*, given}
	property("myProperty") {
	forAll{
	(i: Int) =>
	Scope.confined{
	val ptr = Ptr.blank[CInt]
	!ptr = i
	assertEquals(!ptr, i)
	}
	}
	}
	```
	should be changed to

slinc/core/src/fr/hammons/slinc/modules/ReadWriteModule.scala

Lines 31 to 57 in 8e2ad0c

	val memWriter: Writer[Mem]
	def unionReader(td: TypeDescriptor): Reader[CUnion[? <: NonEmptyTuple]]
	def unionWriter(td: TypeDescriptor): Writer[CUnion[? <: NonEmptyTuple]]
	def write(
	memory: Mem,
	offset: Bytes,
	typeDescriptor: TypeDescriptor,
	value: typeDescriptor.Inner
	): Unit
	def writeArray[A](memory: Mem, offset: Bytes, value: Array[A])(using
	DescriptorOf[A]
	): Unit
	def read(
	memory: Mem,
	offset: Bytes,
	typeDescriptor: TypeDescriptor
	): typeDescriptor.Inner
	def readArray[A](memory: Mem, offset: Bytes, size: Int)(using
	DescriptorOf[A],
	ClassTag[A]
	): Array[A]
	def readFn[A](
	mem: Mem,
	descriptor: CFunctionDescriptor,
	fn: => MethodHandle => Mem => A

slinc/core/docs/_docs/contributing/contributing.md

Lines 33 to 156 in 8e2ad0c

	### Editor
	When developing Slinc, it's suggested to use [VSCode](https://code.visualstudio.com/) along with the [Metals](https://marketplace.visualstudio.com/items?itemName=scalameta.metals) extension. Slinc is heavily dependent on compile-time programming, and VSCode+Metals works very well with this development model. One can use other editors, but it's probably mandatory to use Metals.
	Using metals, one can import the build definition from mill. If one encounters an issue with the import failing for no discernable reason, try deleting the `out` directory and trying again. There is a problem with this project and mill failing to generate bloop configurations. If one encounters errors when viewing a code base that do not resolve themselves, it's suggested to try closing VSCode, killing all Java processes, and deleting .metals, .bloop, and out. Generally, this will fix all issues.
	When developing for Slinc, choose an implementation to focus on, and choose the appropriate JDK for it. Switch with the appropriate `default` command on sdkman, kill all java processes, and afterwards open the project with VSCode. The corresponding `j` project should be having no missing definition errors after this process. Switching between JDK versions follows the same process.
	## Compiling
	The following commands compile the Slinc projecs:
	* core: `./mill core.compile`
	* j17: `./mill j17.compile`
	* j19: `./mill j19.compile`
	* runtime: `./mill runtime.compile`
	Compiling the entire project would normally be done by running `./mill _.compile`, but considering the different project have different JDK requirements, the full compilation takes the form of
	```bash
	sdk u java 17.0.4.1-tem && \
	./mill core.compile && \
	./mill core.test.compile && \
	./mill j17.compile && \
	sdk u java 19-tem && \
	./mill j19.compile && \
	#optional sdk u java 17.0.4.1-tem &&
	./mill runtime.compile
	```
	Only j17 and j19 have a hard dependency on specific JDK major versions. Core and runtime can be compiled with either java 17 or 19 as you wish.
	## Testing
	Tests exist for all portions of the project. They can be executed by running `./mill <project-name>.test`. Examples are:
	* `./mill j17.test`
	* `./mill j19.test`
	* `./mill core.test`
	* `./mill runtime.test`
	Please note that testing runtime involves doing the delicate compilation dance listed above.
	Testing code is generally stored in the `core` project under `core/test/src`. Java 17, Java 19, and runtime specific tests may exist in the future, but at the moment, all implementations use a generic testing base.
	Tests in Slinc use munit and scalacheck. One can read how to use munit with scalacheck [here](https://scalameta.org/munit/docs/integrations/scalacheck.html) and how to use scalacheck [here](https://github.com/typelevel/scalacheck/blob/main/doc/UserGuide.md).
	In order to develop a new test suite for Slinc, add the implementation to `core/test/src`. If the test suite is testing an implementation in `core` then one can define it in the normal way specified by the munit documentation. However, if it's meant to be a test of Slinc implementations, it should be defined in a generic fashion like so:
	```scala
	package fr.hammons.slinc
	import munit.ScalaCheckSuite
	trait MyTestSuite(slinc: Slinc) extends ScalaCheckSuite:
	import slinc.{*,given}
	test("myTest") {
	assertEquals(4,4)
	}
	```
	After defining this in core, add the test to `j17/test/src/fr/hammons/slinc` and `j19/test/src/fr/hammons/slinc` with the following code:
	```scala
	package fr.hammons.slinc
	class MyTestSuite17 extends MyTestSuite(Slinc17.default)
	```
	If one's test suite concerns JIT compilation, one can use `noJit` and `immediate` implementations to make one's test suites test the unjitted and jitted versions of the runtime.
	### Troubleshooting tests
	Sometimes when running a freshly written test, or testing freshly written code, one might encounter a situation where the test suite will stop testing early, or never stop running.
	Generally, the test suite will stop running early when some part of the Slinc runtime fails to initialize properly. One can easily detect if this is the case by moving some test code out of the test section into the root of the suite.
	Observe the following example:
	```scala
	trait MySuite(s: Slinc) extends ScalacheckSuite:
	import s.{*, given}
	test("myTest") {
	assertEquals(sizeOf[Int], 4.as[SizeT]
	}
	```
	should be rewritten to
	```scala
	trait MySuite(s: Slinc) extends ScalacheckSuite:
	import s.{*,given}
	sizeOf[Int]
	4.as[SizeT]
	test("myTest") {
	assertEquals(sizeOf[Int], 4.as[SizeT])
	}
	```
	This tends to force the test suite to actually reveal the exception that's breaking it, and will help one fix the issue in question.
	When a test suite continues forever, the cause is usually the same, but with regards to a propertyBased test:
	```scala
	trait MySuite(s: Slinc) extends ScalacheckSuite:
	import s.{*, given}
	property("myProperty") {
	forAll{
	(i: Int) =>
	Scope.confined{
	val ptr = Ptr.blank[CInt]
	!ptr = i
	assertEquals(!ptr, i)
	}
	}
	}
	```
	should be changed to

---

I'm a bot that handles simple bugs and feature requests but I might make mistakes. Please be kind!