Re: meson: Specify -Wformat as a common warning flag for extensions

From: Sutou Kouhei <kou(at)clear-code(dot)com>
To: peter(at)eisentraut(dot)org
Cc: andres(at)anarazel(dot)de, tristan(at)neon(dot)tech, michael(at)paquier(dot)xyz, pgsql-hackers(at)postgresql(dot)org
Subject: Re: meson: Specify -Wformat as a common warning flag for extensions
Date: 2024-05-29 06:47:08
Message-ID: 20240529.154708.173647409366729418.kou@clear-code.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

In <4707d4ed-f268-43c0-b4dd-cdbc7520f508(at)eisentraut(dot)org>
"Re: meson: Specify -Wformat as a common warning flag for extensions" on Tue, 28 May 2024 23:31:05 -0700,
Peter Eisentraut <peter(at)eisentraut(dot)org> wrote:

> On 07.04.24 18:01, Sutou Kouhei wrote:
>> +# We don't have "warning_level == 3" and "warning_level ==
>> +# 'everything'" here because we don't use these warning levels.
>> +if warning_level == '1'
>> + common_builtin_flags += ['-Wall']
>> +elif warning_level == '2'
>> + common_builtin_flags += ['-Wall', '-Wextra']
>> +endif
>
> I would trim this even further and always export just '-Wall'. The
> other options aren't really something we support.

OK. How about the v6 patch? It always uses '-Wall'.

Thanks,
--
kou

Attachment Content-Type Size
v6-0001-meson-Restore-implicit-warning-debug-optimize-fla.patch text/x-patch 2.8 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrei Lepikhov 2024-05-29 08:08:26 About 0001:,Having overviewed it, I don't see any issues (but I'm the author), except grammatical ones - but I'm not a native to judge it.,Also, the sentence 'turning GROUP BY clauses into pathkeys' is unclear to me. It may be better to write something like: 'building pathkeys by the list of grouping clauses'.,,0002:,The part under USE_ASSERT_CHECKING looks good to me. But the code in group_keys_reorder_by_pathkeys looks suspicious: of course, we do some doubtful work without any possible way to reproduce, but if we envision some duplicated elements in the group_clauses, we should avoid usage of the list_concat_unique_ptr. What's more, why do you not exit from foreach_ptr immediately after SortGroupClause has been found? I think the new_group_clauses should be consistent with the new_group_pathkeys.,,0003:,Looks good,,0004:,I was also thinking about reintroducing the preprocess_groupclause because with the re-arrangement of GROUP-BY clauses according to incoming pathkeys, it doesn't make sense to have a user-defined order—at least while cost_sort doesn't differ costs for alternative column orderings.,So, I'm okay with the code. But why don't you use the same approach with foreach_ptr as before?
Previous Message Peter Eisentraut 2024-05-29 06:41:06 meson "experimental"?