New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add To/FromValue trait to VariantType #340

Merged
merged 6 commits into from Jun 22, 2018

Conversation

Projects
None yet
4 participants
@vhdirk

vhdirk commented Jun 18, 2018

This PR enables wrapping a VariantTy(pe) in Value

@GuillaumeGomez

This comment has been minimized.

Show comment
Hide comment
@GuillaumeGomez
Member

GuillaumeGomez commented Jun 18, 2018

@sdroege

Looks good but incomplete. Please add both directions for both types :)

Show outdated Hide outdated src/variant_type.rs
Show outdated Hide outdated src/variant_type.rs
@vhdirk

This comment has been minimized.

Show comment
Hide comment
@vhdirk

vhdirk Jun 20, 2018

How come a VariantType can't be null? This test seems to tell otherwise? https://gitlab.gnome.org/GNOME/glib/blob/master/gio/tests/actions.c

vhdirk commented Jun 20, 2018

How come a VariantType can't be null? This test seems to tell otherwise? https://gitlab.gnome.org/GNOME/glib/blob/master/gio/tests/actions.c

@sdroege

This comment has been minimized.

Show comment
Hide comment
@sdroege

sdroege Jun 20, 2018

Member

How come a VariantType can't be null? This test seems to tell otherwise? https://gitlab.gnome.org/GNOME/glib/blob/master/gio/tests/actions.c

Inside GValue it is using g_variant_type_copy(), which will assert if NULL is passed:
https://gitlab.gnome.org/GNOME/glib/blob/b9aed426d198ccf27078263d982bb247c82ccaee/glib/gvarianttype.c#L330 and https://gitlab.gnome.org/GNOME/glib/blob/b9aed426d198ccf27078263d982bb247c82ccaee/glib/gvarianttype.c#L184-188

That might be a bug on the GLib side though. Do you need it to be NULL for anything?

Member

sdroege commented Jun 20, 2018

How come a VariantType can't be null? This test seems to tell otherwise? https://gitlab.gnome.org/GNOME/glib/blob/master/gio/tests/actions.c

Inside GValue it is using g_variant_type_copy(), which will assert if NULL is passed:
https://gitlab.gnome.org/GNOME/glib/blob/b9aed426d198ccf27078263d982bb247c82ccaee/glib/gvarianttype.c#L330 and https://gitlab.gnome.org/GNOME/glib/blob/b9aed426d198ccf27078263d982bb247c82ccaee/glib/gvarianttype.c#L184-188

That might be a bug on the GLib side though. Do you need it to be NULL for anything?

@vhdirk

This comment has been minimized.

Show comment
Hide comment
@vhdirk

vhdirk Jun 20, 2018

That might be a bug on the GLib side though. Do you need it to be NULL for anything?

Not necessarily. Only for aping SimpleAction

vhdirk commented Jun 20, 2018

That might be a bug on the GLib side though. Do you need it to be NULL for anything?

Not necessarily. Only for aping SimpleAction

@sdroege

This comment has been minimized.

Show comment
Hide comment
@sdroege

sdroege Jun 20, 2018

Member

That might be a bug on the GLib side though. Do you need it to be NULL for anything?

Not necessarily. Only for aping SimpleAction

How does it work in SimpleAction (why does it not run into these assertions?), what are the NULL types used for exactly?

Member

sdroege commented Jun 20, 2018

That might be a bug on the GLib side though. Do you need it to be NULL for anything?

Not necessarily. Only for aping SimpleAction

How does it work in SimpleAction (why does it not run into these assertions?), what are the NULL types used for exactly?

@vhdirk

This comment has been minimized.

Show comment
Hide comment
@vhdirk

vhdirk Jun 20, 2018

The docs of SimpleAction state:

The type of the parameter that must be given when activating the action.

I've never used GAction before, so I'm not sure what that means. And my rust version of SimpleAction is still panicking somewhere without a clear trace...

vhdirk commented Jun 20, 2018

The docs of SimpleAction state:

The type of the parameter that must be given when activating the action.

I've never used GAction before, so I'm not sure what that means. And my rust version of SimpleAction is still panicking somewhere without a clear trace...

@vhdirk

This comment has been minimized.

Show comment
Hide comment
@vhdirk

vhdirk Jun 20, 2018

More from the docs

Since GLib 2.40, if no handler is connected to this signal then the default behaviour for boolean-stated actions with a NULL parameter type is to toggle them via the “change-state” signal.

vhdirk commented Jun 20, 2018

More from the docs

Since GLib 2.40, if no handler is connected to this signal then the default behaviour for boolean-stated actions with a NULL parameter type is to toggle them via the “change-state” signal.

@sdroege

This comment has been minimized.

Show comment
Hide comment
@sdroege

sdroege Jun 20, 2018

Member

That hints at a bug in GLib then, that clearly says that NULL types are expected behaviour... but running g_boxed_copy() on such GValues (as from the signals) would assert. Can you file a bug against GLib about that?

Member

sdroege commented Jun 20, 2018

That hints at a bug in GLib then, that clearly says that NULL types are expected behaviour... but running g_boxed_copy() on such GValues (as from the signals) would assert. Can you file a bug against GLib about that?

@vhdirk

This comment has been minimized.

Show comment
Hide comment
@vhdirk

vhdirk Jun 20, 2018

From what I can tell, it is not so much GValueType that is not nullable, rather the type string itself?

vhdirk commented Jun 20, 2018

From what I can tell, it is not so much GValueType that is not nullable, rather the type string itself?

@sdroege

This comment has been minimized.

Show comment
Hide comment
@sdroege

sdroege Jun 21, 2018

Member

From what I can tell, it is not so much GValueType that is not nullable, rather the type string itself?

I'm not sure what you mean with this. GVariantType seems to be possible to be NULL in various contexts, just not when stored in a GValue (but GSimpleAction seems to use it as such nonetheless).

Member

sdroege commented Jun 21, 2018

From what I can tell, it is not so much GValueType that is not nullable, rather the type string itself?

I'm not sure what you mean with this. GVariantType seems to be possible to be NULL in various contexts, just not when stored in a GValue (but GSimpleAction seems to use it as such nonetheless).

@vhdirk

This comment has been minimized.

Show comment
Hide comment
@vhdirk

vhdirk Jun 21, 2018

Looking at the implementation of g_variant_type_copy, I think the documentation is wrong.

GVariantType *
g_variant_type_copy (const GVariantType *type)
{
  gsize length;
  gchar *new;

  g_return_val_if_fail (g_variant_type_check (type), NULL);

  <snip>
}

There's no assertion here. It will just return another null pointer when you provide it a null pointer.

vhdirk commented Jun 21, 2018

Looking at the implementation of g_variant_type_copy, I think the documentation is wrong.

GVariantType *
g_variant_type_copy (const GVariantType *type)
{
  gsize length;
  gchar *new;

  g_return_val_if_fail (g_variant_type_check (type), NULL);

  <snip>
}

There's no assertion here. It will just return another null pointer when you provide it a null pointer.

@sdroege

This comment has been minimized.

Show comment
Hide comment
@sdroege

sdroege Jun 21, 2018

Member

g_return_val_if_fail (g_variant_type_check (type), NULL);

This is an assertion (it will return FALSE for NULL)

Member

sdroege commented Jun 21, 2018

g_return_val_if_fail (g_variant_type_check (type), NULL);

This is an assertion (it will return FALSE for NULL)

@vhdirk

This comment has been minimized.

Show comment
Hide comment
@vhdirk

vhdirk Jun 21, 2018

Are you sure?

According to the docs:

#define             g_return_val_if_fail(expr,val)

It will return val if expr evaluates to FALSE.

So in this case, it will return NULL when g_variant_type_check(type) returns FALSE. Which is the case when type is NULL to begin with.

vhdirk commented Jun 21, 2018

Are you sure?

According to the docs:

#define             g_return_val_if_fail(expr,val)

It will return val if expr evaluates to FALSE.

So in this case, it will return NULL when g_variant_type_check(type) returns FALSE. Which is the case when type is NULL to begin with.

@sdroege

This comment has been minimized.

Show comment
Hide comment
@sdroege

sdroege Jun 21, 2018

Member

It's only to be used as a guard against programming mistakes. It's an assertion, but not taking down your application unless yet set G_DEBUG=fatal_criticals. It causes a g_critical() warning, which is also printed on stderr.

Member

sdroege commented Jun 21, 2018

It's only to be used as a guard against programming mistakes. It's an assertion, but not taking down your application unless yet set G_DEBUG=fatal_criticals. It causes a g_critical() warning, which is also printed on stderr.

@vhdirk

This comment has been minimized.

Show comment
Hide comment
@vhdirk

vhdirk Jun 21, 2018

Ah, I though that was just a shorthand. So yeah, this is a bug in glib then.

vhdirk commented Jun 21, 2018

Ah, I though that was just a shorthand. So yeah, this is a bug in glib then.

@sdroege

This comment has been minimized.

Show comment
Hide comment
@sdroege

sdroege Jun 21, 2018

Member

Ah, I though that was just a shorthand. So yeah, this is a bug in glib then.

Lovely :) Not sure what we can do about that, need a workaround until a new GLib version arrives. But your code making it nullable is correct then, just GLib isn't correct.

Member

sdroege commented Jun 21, 2018

Ah, I though that was just a shorthand. So yeah, this is a bug in glib then.

Lovely :) Not sure what we can do about that, need a workaround until a new GLib version arrives. But your code making it nullable is correct then, just GLib isn't correct.

@sdroege

This comment has been minimized.

Show comment
Hide comment
@sdroege

sdroege Jun 21, 2018

Member

I would suggest to file a bug there and go ahead with your implementation. It will not cause unsafety, it only causes ugly warnings on the terminal and those are GLib's problem

Member

sdroege commented Jun 21, 2018

I would suggest to file a bug there and go ahead with your implementation. It will not cause unsafety, it only causes ugly warnings on the terminal and those are GLib's problem

@sdroege

This comment has been minimized.

Show comment
Hide comment
@sdroege

sdroege Jun 21, 2018

Member

Looks good to me, but please also link to the GLib bug report about this here for future reference

Member

sdroege commented Jun 21, 2018

Looks good to me, but please also link to the GLib bug report about this here for future reference

@vhdirk

This comment has been minimized.

Show comment
Hide comment
@vhdirk

vhdirk Jun 21, 2018

I'll create the glib bug report soon.

vhdirk commented Jun 21, 2018

I'll create the glib bug report soon.

@vhdirk

This comment has been minimized.

Show comment
Hide comment
@sdroege

This comment has been minimized.

Show comment
Hide comment
@sdroege

sdroege Jun 22, 2018

Member

@GuillaumeGomez Let's get this in then?

Member

sdroege commented Jun 22, 2018

@GuillaumeGomez Let's get this in then?

@GuillaumeGomez

This comment has been minimized.

Show comment
Hide comment
@GuillaumeGomez

GuillaumeGomez Jun 22, 2018

Member

Yes! Thanks @vhdirk!

Member

GuillaumeGomez commented Jun 22, 2018

Yes! Thanks @vhdirk!

@GuillaumeGomez GuillaumeGomez merged commit f016524 into gtk-rs:master Jun 22, 2018

1 of 2 checks passed

continuous-integration/travis-ci/pr The Travis CI build failed
Details
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment