Ping
Den lör 5 jan. 2019 kl 20:44 skrev Daniel Marjamäki
:
>
> Here is a new patch with fixed comments and indentation
>
> diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
> index 972b629c092..294ff34fe55 100644
> --- a/gcc/c/c-parser.c
> +++ b/gcc/c/c-parser.c
> @@
@@
+
+/* { dg-do compile } */
+
+void f1() {
+ int a = 0)+3; /* { dg-error "unmatched" } */
+}
+
+void f2() {
+ int b = (1]+3; /* { dg-error "expected" } */
+}
+
+void f3() {
+ int b = 1]+3; /* { dg-error "unmatched" } */
+}
+
+void f4() {
+ int c = (1))+3; /* {
boring comments:
>
> On Fri, Jan 04, 2019 at 09:25:10PM +0100, Daniel Marjamäki wrote:
> > The first reason is the hard problem, but maybe we can ignore this now also:
> >
> > void f()
> > {
> > } // <- looking at the indentation, it seems preferable to warn a
+++ b/gcc/testsuite/gcc.dg/unmatched.c
@@ -0,0 +1,19 @@
+
+/* { dg-do compile } */
+
+void f1() {
+ int a = 0)+3; /* { dg-error "unmatched" } */
+}
+
+void f2() {
+ int b = (1]+3; /* { dg-error "expected" } */
+}
+
+void f3() {
+ int b = 1]+3; /* { dg-error "unmatched" } */
+}
+
+void f4() {
+ int c = (1))+3; /* { dg-error "unmatched" } */
+}
+
Best regards,
Daniel Marjamäki
ake sense to emit a fix-it hint suggesting the removal of the
> stray token.
It is 50% chance that the closing paranthesis should be removed. Maybe
there is a missing "(".
Maybe the error message should indicate that.. something like "either
there is missing "(" or this ")" is a stray token".
Best regards,
Daniel Marjamäki
when there is a unmatched extra ) or } or ] then
it should just say "extraneous .." instead of "expected ',' or ';'.
Adding a ',' or ';' in the example code will not fix the syntax error.
Best regards,
Daniel Marjamäki
> What if the object being constructed has only POD-type members with constant
> initializers but is declared volatile
I don't understand really... but it doesn't matter, I give up.
>
> If the initializer is constant, but the member value that's being
> initialized has a
> non-trivial constructor with a side effect, your patch will inhibit the
> warning
> but the program will not behave the same as if reordering had not happened.
>
> Peter
>
Yes. It sounds unlikely. But not
2011/7/30 Joern Rennecke :
> Quoting Jonathan Wakely :
>
>> I would object to changing the behaviour, or if it changes then it
>> should be controllable so I can continue to get the current behaviour,
>> e.g. -Wreorder=0 does what you propose, -Wreorder=1 does what we have
>> now, and -Wreorder is
2011/7/29 Richard Guenther :
> 2011/7/29 Daniel Marjamäki :
>> Hello!
>>
>>> Why doesn't it matter in this case but it matters when the initializer
>>> are non-constant?
>>
>> It doesn't matter because the program will behave the same n
Hello!
> Why doesn't it matter in this case but it matters when the initializer
> are non-constant?
It doesn't matter because the program will behave the same no matter
if the initializations are reordered or not. Logically it will behave
just as the user expects no matter if he expects reorderin
Hello!
In my humble opinion the -Wreorder has noise. When the order doesn't
matter I would prefer that warnings are not issued.
In this email I include a patch that I would like to get comments
about. The patch will suppress warnings if all members are initialized
with constant values.
I am not v
Hello Pierre!
It is an interesting plugin. I'll keep an eye on your repository.
Thanks!
Daniel Marjamäki
2011/2/9 Pierre Vittet :
> Hello,
>
> I would like to present you a small plugin, which could be a good exemple of
> a MELT use case.
> This plugin allows to monitor t
Hello!
In my humle opinion it would be useful with some sample plugins. For
example on one of these pages:
http://gcc.gnu.org/wiki/plugins
http://gcc.gnu.org/onlinedocs/gccint/Plugins.html
I have created two sample plugins that are available here:
http://www.github.com/danmar/gcc-plugins
Feel fr
I see. Good.
2011/1/27 Tom Tromey :
>> "Ian" == Ian Lance Taylor writes:
>
> Ian> The problem with warnings for this kind of code in C/C++ is that it
> Ian> often arises in macro expansions. I think it would be necessary to
> Ian> first develop a scheme which lets us determine whether code r
2011/1/24 Ian Lance Taylor :
> Daniel Marjamäki writes:
>
>> 2011/1/24 Ian Lance Taylor :
>>
>>> The problem with warnings for this kind of code in C/C++ is that it
>>> often arises in macro expansions.
>>
>> I see... so it won't be included i
2011/1/24 Ian Lance Taylor :
> The problem with warnings for this kind of code in C/C++ is that it
> often arises in macro expansions.
I see... so it won't be included in gcc. :-(
It was my goal to get it into GCC. But I still think it's an
interesting idea that I'll look into.
Regards,
Daniel
Do you have any opinion about adding a warning for:
int f(char c)
{
return 10 * (c == 13) ? 1 : 2;
}
The multiplication has no effect. The function returns either 1 or 2.
It would be interesting to know how a MELT script could look like for
such a case.
As far as I see the multiplication do
It is well written but it
doesn't have much example code. Do you know about any simple example
code?
Regards,
Daniel
2011/1/23 Dave Korn :
> On 23/01/2011 10:58, Daniel Marjamäki wrote:
>
>> I fail to use 'global_namespace':
>> daniel@daniel:~/gcc/build/gcc
GCC-MELT is an interesting project. But it seems to be very difficult
to write lisp scripts. You don't have a C interface also, do you?
I would like to see how I can use plain C.
Regards,
Daniel
2011/1/23 Basile Starynkevitch :
> On Sun, 23 Jan 2011 11:58:21 +0100
> Daniel Marja
lugin_gcc_version *version)
{
printf("myplugin1\n");
register_callback(plugin_info->base_name,
PLUGIN_OVERRIDE_GATE,
&override_gate,
0);
return 0;
}
Best regards,
Daniel Marjamäki
21 matches
Mail list logo
