vala issueshttps://gitlab.gnome.org/GNOME/vala/-/issues2020-11-20T12:21:24Zhttps://gitlab.gnome.org/GNOME/vala/-/issues/299Async methods don't perform parameter checks2020-11-20T12:21:24ZBugzillaAsync methods don't perform parameter checks## Submitted by Eric Gregory
**[Link to original bug (#676203)](https://bugzilla.gnome.org/show_bug.cgi?id=676203)**
## Description
Created attachment 214223
Test case demonstrating the issue
With normal Vala methods, a sanity chec...## Submitted by Eric Gregory
**[Link to original bug (#676203)](https://bugzilla.gnome.org/show_bug.cgi?id=676203)**
## Description
Created attachment 214223
Test case demonstrating the issue
With normal Vala methods, a sanity check is performed to ensure the parameters are of the expected types. This doesn't seem to be happening in async methods in Vala 0.17.0
I've attached a test case that demonstrates the issue. The test() method will fail with "CRITICAL **: test: assertion `s != NULL' failed"
The async version, test_async(), triggers an assertion inside g_utf8_strup() instead.
A quick look at the generated C code shows that test() performs a null check, whereas the methods corresponding with test_async() do not.
Note that I only used the string type here as an example -- the same issue occurs with any type, including Vala classes.
**Attachment 214223**, "Test case demonstrating the issue":
[test.vala](/uploads/780db3f2b76eaa92d38aca10472c0f45/test.vala)0.50https://gitlab.gnome.org/GNOME/vala/-/issues/995Async generated code is dropping a parameter2020-08-20T02:46:05ZMichael TerryAsync generated code is dropping a parameterGenerated code can sometimes drop a parameter specified in the vala source. I hit this when using libsecret, but am not sure if it's related to that library's bindings or not.
**To reproduce:**
1. Download the `test.vala` file attached ...Generated code can sometimes drop a parameter specified in the vala source. I hit this when using libsecret, but am not sure if it's related to that library's bindings or not.
**To reproduce:**
1. Download the `test.vala` file attached to this issue.
2. Compile it like so: `valac --pkg gio-2.0 --pkg libsecret-1 -C test.vala`
3. Run `grep password_lookup test.c`
**Current output** (with valac 0.48.5 on Ubuntu 20.04 and libsecret 0.20.2):
```
_data_->_tmp2_ = secret_password_lookup_sync (_data_->_tmp1_, NULL, &_data_->_inner_error0_, "key", "val", NULL);
secret_password_lookup (_data_->_tmp4_, NULL, lookup_ready, _data_, "val", NULL);
```
You'll notice that the "key" parameter got dropped in the async code.
The libsecret bindings I have at time of writing are, in case they are partly to blame:
```
[CCode (cheader_filename = "libsecret/secret.h")]
public static async string password_lookup (Secret.Schema schema, GLib.Cancellable? cancellable, ...) throws GLib.Error;
[CCode (cheader_filename = "libsecret/secret.h")]
public static string password_lookup_sync (Secret.Schema schema, GLib.Cancellable? cancellable = null, ...) throws GLib.Error;
```
[test.vala](/uploads/1a945da231fbe8ae6a7856a6b30feedd/test.vala)0.48Rico TzschichholzRico Tzschichholzhttps://gitlab.gnome.org/GNOME/vala/-/issues/954Inline-allocated arrays with initializer list don't work in async methods2020-04-21T13:27:41ZEmill32143-Emill@users.noreply.gitlab.gnome.orgInline-allocated arrays with initializer list don't work in async methodsVala code:
```vala
async void func() {
int arr[] = {1, 2};
}
```
Generated C code:
```c
struct _FuncData {
int _state_;
GObject* _source_object_;
GAsyncResult* _res_;
GTask* _async_result;
GAsyncReadyCallback _callback_;
gboo...Vala code:
```vala
async void func() {
int arr[] = {1, 2};
}
```
Generated C code:
```c
struct _FuncData {
int _state_;
GObject* _source_object_;
GAsyncResult* _res_;
GTask* _async_result;
GAsyncReadyCallback _callback_;
gboolean _task_complete_;
gint arr[2];
gint _tmp0_;
};
...
static gboolean
func_co (FuncData* _data_)
{
...
memset (&_data_->_tmp0_, 0, sizeof (gint));
_data_->_tmp0_[0] = 1;
_data_->_tmp0_[1] = 2;
memcpy (_data_->arr, _data_->_tmp0_, 2 * sizeof (gint));
...
}
```
But `_tmp0_` is not an array, so the gcc compilation fails.0.48