This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH v2] Class-ify ptid_t
- From: Simon Marchi <simon dot marchi at ericsson dot com>
- To: Pedro Alves <palves at redhat dot com>, Philipp Rudo <prudo at linux dot vnet dot ibm dot com>
- Cc: <gdb-patches at sourceware dot org>
- Date: Fri, 7 Apr 2017 10:33:39 -0400
- Subject: Re: [PATCH v2] Class-ify ptid_t
- Authentication-results: sourceware.org; auth=none
- Authentication-results: sourceware.org; dkim=none (message not signed) header.d=none;sourceware.org; dmarc=none action=none header.from=ericsson.com;
- References: <20170406190328.21103-1-simon.marchi@ericsson.com> <20170407112528.3f03fd37@ThinkPad> <5adec1b9-2faf-d8af-0116-c237ee591738@redhat.com>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
On 17-04-07 06:48 AM, Pedro Alves wrote:
> On 04/07/2017 10:25 AM, Philipp Rudo wrote:
>
>> In this context I ask myself what the error message is supposed to
>> say (unfortunately you are the first one in GDB actually using it, all
>> others only use an empty string). Is it what's expected ...
>>
>
> That's because the static assertion failure text includes both a
> file:line indicating where's the failure, and modern gcc/clang
> show you the line that failed, so it's not that big of a deal to
> not include a message:
>
> src/gdb/thread.c:1589:1: error: static assertion failed:
> static_assert (1 == 0, "");
> ^
> $
>
> (and in C++17, static_assert got an overload with no second
> parameter, even.)
>
>>
>> static_assert (pid == ptid_t (1, 0, 0), "pid operator== returned false")
>>
>>
>> I tend more to what is expected.
>
> Definitely it should say what is expected, just like regular
> testsuite tests. Or say nothing when the expression is pretty clear
> already, which works for me too. :-)
Heh, why did you not say that earlier, it would have saved me some time ;)
@Philipp: To come back to the verb tense thing. Now that I think of it, when
I read the lines, I mentally insert a "that" in there. So
static_assert (!pid.matches (lwp), "pid doesn't match lwp");
becomes mentally
assert that pid doesn't match lwp
I think it comes from using jUnit's assertThat:
https://github.com/junit-team/junit4/wiki/matchers-and-assertthat
Simon