c#: Use stack when the list is smaller than a given value #1144
Conversation
Signed-off-by: James Sturtevant <[email protected]>
| {{ | ||
| var {buffer_size} = {size} * (nuint){list}.Count; | ||
| {address} = NativeMemory.AlignedAlloc({buffer_size}, {align}); | ||
| cleanups.Add(()=> NativeMemory.AlignedFree({address})); |
There was a problem hiding this comment.
Wishful thinking - not blocked for this PR:
It would be awesome if we could see this in context of some generated sample.
Maybe we can have wit->C# integration test in which the C# file is committed into git ?
That would show up as delta in the generated code in the PR.
There was a problem hiding this comment.
There are tons of integration tests in https://github.com/bytecodealliance/wit-bindgen/tree/main/tests
Currently we don't check any into source, but having something like the that does have some value. I typically pull a PR and take a look at the source changes if I am unsure so would find this useful.
@alexcrichton any thoughts on this? I suppose the Rust version is a macro so you don't really have source to check in?
There was a problem hiding this comment.
It's possible to finagle but would require some frobbing of the infrastructure. We do this in Wasmtime for example for the output of the wasmtime::component::bindgen! macro and we could do something similar for the generators in this repository. Most generators are already running "codegen tests" to ensure the output compiles and we could probably update that all to save/restore snapshots in-tree. Probably wouldn't run the tests themselves but you'd still be able to see diffs in PRs.
Personally I like having "golden snapshot" tests like that in-tree and I also like to review output changes as opposed to changes-of-how-to-output-code. The only downside is "big PRs" but I find it pretty easy to skim over the generated code changes.
Basically that's a long-winded way of saying that I think it'd be quite reasonable to add this to the repo. Basically run bindings generation for everything in tests/codegen and check in the results in-tree.
There was a problem hiding this comment.
I was thinking that we didn't need to have every test in tests/codegen but maybe something like the flavorful example checked in? I think it might be overwhelming to have to many files changed in a PR. Anyways I will open an issue to track.
|
I'm happy to rubber-stamp these (or ask @dicej) to rubber stamp them, but @jsturtevant do you have someone else in mind to review C#-related PRs? I'm happy to add someone else to this repository for reviewing things to assist with assignment/merging/etc. (mostly want to clarify your expectations around reviewing since I'm not able to review C# code myself) |
Typically try to get a review from the C# maintainers: @silesmo, @yowl or @dicej. @pavelsavara is our upstream .NET contributor that could offer C#/.net advice too. @pavelsavara are you interested in joining the repo for c# reviews? |
|
Ok sounds good 👍 Mostly wanted to make sure you weren't blocking on my and I wasn't aware of it! |
Yes |
fixes #1012