Implement partial support for variadic parameters #485

derppening · 2024-08-05T16:45:08+08:00

derppening commented

2024-08-05 16:45:08 +08:00

Variadic functions in Python can now be declared and called. The support is only "partial" as we currently do not have a way to access the variadic arguments in Python.

To test this branch:

Cherry-pick the commit from misc/impl-tracert (to provide call_prinf).
Apply the patch below.
Run the vararg.py demo, and observe the following output:

Variadic functions in Python can now be declared and called. The support is only "partial" as we currently do not have a way to access the variadic arguments in Python. To test this branch: 1. Cherry-pick the commit from `misc/impl-tracert` (to provide `call_prinf`). 2. Apply the patch below. 3. Run the `vararg.py` demo, and observe the following output: ``` 0 1 1 2 1 2 3 1 2 3 ```

WIP_-_core__Output_passed_vararg_arguments.patch

3.1 KiB

derppening force-pushed feature/vararg-param from 0bdecd4b9c to 346f69b5d8

2024-08-05 16:48:15 +08:00

Compare

sb10q reviewed 2024-08-05 19:08:17 +08:00

nac3core/src/codegen/mod.rs Outdated

						
				@ -610,0 +626,4 @@

				        ("i386" | "i486" | "i586" | "i686" | "amd64" | "x86_64" | "x86_64h", 32) => {

				            ctx.i8_type().ptr_type(AddressSpace::default()).into()

				        }

				        ("amd64" | "x86_64" | "x86_64h", 64) => {

sb10q commented

2024-08-05 19:08:17 +08:00

I don't understand why this usize issue is popping up again.
Isn't llvm_usize.get_bit_width() fixed for a given arch ?

I don't understand why this usize issue is popping up again. Isn't ``llvm_usize.get_bit_width()`` fixed for a given ``arch`` ?

derppening commented

2024-08-06 11:48:56 +08:00

Removed.

sb10q commented

2024-08-06 11:49:15 +08:00

Are there still other parts of the codebase where this remains a problem?

derppening commented

2024-08-06 12:06:13 +08:00

I don't think there's anywhere else where size_t is used to determine logic that is not directly related to codegen. However, there are still some parts of the codebase that may be best refactored, e.g. range (which is currently tuple[int32, int32, int32]) and len (which always returns int32).

I don't think there's anywhere else where `size_t` is used to determine logic that is not directly related to codegen. However, there are still some parts of the codebase that may be best refactored, e.g. `range` (which is currently `tuple[int32, int32, int32]`) and `len` (which always returns `int32`).

sb10q commented

2024-08-06 12:07:23 +08:00

I think range should return the same as the type of its arguments, and len should be size_t.

I think ``range`` should return the same as the type of its arguments, and ``len`` should be ``size_t``.