After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 704072 - add assert() variants similar to g_assert_cmp*()
add assert() variants similar to g_assert_cmp*()
Status: RESOLVED OBSOLETE
Product: vala
Classification: Core
Component: Code Generator
unspecified
Other Linux
: Normal enhancement
: ---
Assigned To: Vala maintainers
Vala maintainers
Depends on:
Blocks:
 
 
Reported: 2013-07-12 09:02 UTC by Daiki Ueno
Modified: 2018-05-22 14:53 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
codegen: Emit g_assert_cmp*() call for assert (a OP b) if possible (4.28 KB, patch)
2014-03-03 08:32 UTC, Daiki Ueno
none Details | Review
codegen: Emit assertion code using g_assertion_message_cmp{str,num} (5.95 KB, patch)
2014-03-19 04:44 UTC, Daiki Ueno
none Details | Review

Description Daiki Ueno 2013-07-12 09:02:25 UTC
In my project, I have a lot of test cases which compare strings.  The built-in assert() function is not so helpful for failure cases, since it doesn't print the actual value evaluated.

What do you think about adding some variants of assert(), like g_assert_cmpstr() in glib or assertEqual() in python?  I guess it requires changes to codegen to generate the macros in C, and new code attributes to call them.
Comment 1 Daiki Ueno 2014-02-27 03:19:48 UTC
I still badly want this feature, so here is a proposal for a naive implementation:

1. Introduce a new attribute which marks an argument that will be "unquoted" in codegen, something like:

  [Assert (operator_pos = 1.1)]
  public void assert_cmpstr (string s1, string cmp, string s2);

or more generic:

  [Assert]
  public void assert_cmpstr (string s1, [CCode (quoted = true)] string cmp, string s2);

2. In Vala code, write tests with the CMP argument quoted as a string:

  assert_cmpstr (a, ">", b);

3. Codegen translates it to:

  g_assert_cmpstr (a, >, b);

How does this sound?  I know it's not elegant though.
Comment 2 Luca Bruno 2014-02-27 08:22:29 UTC
Sounds good, that also opens a new world of hacks :P
Does this work already maybe?

[CCode (cname=">")]
public const string GT;

assert_cmpstr(a, GT, b);
Comment 3 Daiki Ueno 2014-02-27 09:03:22 UTC
Oh, yes, it works like a charm!  Thanks for the info.
So, maybe those assert_cmp*() and GT, LT, etc. could be simply added to glib-2.0.vapi?
Comment 4 Luca Bruno 2014-02-27 09:17:46 UTC
Yes, probably for now it's better to avoid extending the syntax for such cases. Don't know if Jurg has a better solution.
Comment 5 Jürg Billeter 2014-02-27 09:34:41 UTC
I don't see a reason to add syntax for it. However, the compiler could recognize the usual

    assert (a < b);

and translate it to g_assert_cmp* as appropriate. We already have special handling for assert to provide an understandable message, however, that would be a good improvement.
Comment 6 Daiki Ueno 2014-03-03 08:30:21 UTC
Yes, that would be ideal, as we can get detailed diagnostics without any modification to the existing test code.  FWIW, I'm attaching a patch.
Comment 7 Daiki Ueno 2014-03-03 08:32:09 UTC
Created attachment 270761 [details] [review]
codegen: Emit g_assert_cmp*() call for assert (a OP b) if possible
Comment 8 Luca Bruno 2014-03-06 20:35:19 UTC
Thanks for your patch, however using directly g_assert won't point you to the relevant vala code. Why are you avoiding the _vala_assert approach?
The vala source reference must be written in the assert message, using _vala variants of glib asserts, otherwise whenever an assert happens you don't know where it happened.
Comment 9 Daiki Ueno 2014-03-19 04:44:02 UTC
Created attachment 272354 [details] [review]
codegen: Emit assertion code using g_assertion_message_cmp{str,num}

--
Right, thanks for looking at it.  The new patch will fix it, although I gave up dealing with nullable value types.
Comment 10 GNOME Infrastructure Team 2018-05-22 14:53:04 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/vala/issues/395.