> It wouldn't be awful, but we do not want to allow assignments to these
> things. That's why that's there, and undefined.
>
> Riki
> Is not your patch like:
>
> InsetTableCell::InsetTableCell(InsetTableCell const & in) = default;
>
> Or I am in the wrong standard?
> --
> José Abílio
If
Le 7 octobre 2020 02:32:06 GMT+02:00, Richard Kimberly Heck
a écrit : InsetTableCell::InsetTableCell(InsetTableCell const & in) = default;
>>
>>
>> Or I am in the wrong standard?
>>
>I think this must be the magic JMarc was looking for. This is in C++11,
>so OK for us, right?
I like it!
JMarc
On 10/6/20 8:18 PM, José Abílio Matos wrote:
>
> On Monday, October 5, 2020 6:27:15 PM WEST Richard Kimberly Heck wrote:
>
> > I'm actually not sure why the assignment operator is made unavailable,
>
> > but attached is a suitable patch, I think.
>
> >
>
> > Riki
>
>
> Is not your patch like:
>
>
On Monday, October 5, 2020 6:27:15 PM WEST Richard Kimberly Heck wrote:
> I'm actually not sure why the assignment operator is made unavailable,
> but attached is a suitable patch, I think.
>
> Riki
Is not your patch like:
InsetTableCell::InsetTableCell(InsetTableCell const & in) = default;
Or
On 10/6/20 5:29 PM, Pavel Sanda wrote:
> On Tue, Oct 06, 2020 at 11:04:55PM +0200, Jean-Marc Lasgouttes wrote:
>> Le 05/10/2020 ?? 19:27, Richard Kimberly Heck a écrit :
PS: yes, a proper fix will be eventually required, but I do not really
know what we should do.
>>> I'm actually not
On Tue, Oct 06, 2020 at 11:04:55PM +0200, Jean-Marc Lasgouttes wrote:
> Le 05/10/2020 ?? 19:27, Richard Kimberly Heck a écrit :
> >>PS: yes, a proper fix will be eventually required, but I do not really
> >>know what we should do.
> >
> >I'm actually not sure why the assignment operator is made
Le 05/10/2020 à 19:27, Richard Kimberly Heck a écrit :
PS: yes, a proper fix will be eventually required, but I do not really
know what we should do.
I'm actually not sure why the assignment operator is made unavailable,
but attached is a suitable patch, I think.
It looks reasonable, but I
Le 05/10/2020 à 21:38, José Abílio Matos a écrit :
I created a new directory. And then ran configure on that directory using the
CC and CXX environment variables to force clang.
This is what I get. I am using qt-5.15.1 FWIW:
/home/jamatos/lyx/lyx/src/frontends/qt/GuiView.cpp:221:11: warning:
On Monday, October 5, 2020 6:09:40 PM WEST Jean-Marc Lasgouttes wrote:
> Le 05/10/2020 à 18:43, José Abílio Matos a écrit :
> > On Monday, October 5, 2020 5:19:46 PM WEST Jean-Marc Lasgouttes wrote:
> >> Fixed
> >>
> >> JMarc
> >
> > Now, if I may ask what about the following kind of warning:
>
On 10/5/20 12:19 PM, Jean-Marc Lasgouttes wrote:
> Le 05/10/2020 à 17:50, José Abílio Matos a écrit :
>> On Monday, October 5, 2020 2:13:35 PM WEST Jean-Marc Lasgouttes wrote:
>>> Yes, clang 10 does
>>>
>>> JMarc
>>
>> BTW compiling with clang 11 and without changing the compile flags I
>> get
Le 05/10/2020 à 18:43, José Abílio Matos a écrit :
On Monday, October 5, 2020 5:19:46 PM WEST Jean-Marc Lasgouttes wrote:
Fixed
JMarc
Now, if I may ask what about the following kind of warning:
In file included from ./ui_TabularUi.h:28:
On Monday, October 5, 2020 5:19:46 PM WEST Jean-Marc Lasgouttes wrote:
> Fixed
>
> JMarc
Now, if I may ask what about the following kind of warning:
In file included from ./ui_TabularUi.h:28:
/home/jamatos/lyx/lyx/src/frontends/qt/GuiSetBorder.h:30:59: warning: 'QFlags'
is deprecated: Use
Le 05/10/2020 à 17:50, José Abílio Matos a écrit :
On Monday, October 5, 2020 2:13:35 PM WEST Jean-Marc Lasgouttes wrote:
Yes, clang 10 does
JMarc
BTW compiling with clang 11 and without changing the compile flags I get lots
(in the tens) of warnings like this:
On 10/5/20 11:50 AM, José Abílio Matos wrote:
> On Monday, October 5, 2020 2:13:35 PM WEST Jean-Marc Lasgouttes wrote:
>> Yes, clang 10 does
>>
>> JMarc
> BTW compiling with clang 11 and without changing the compile flags I get lots
> (in the tens) of warnings like this:
>
>
On Monday, October 5, 2020 2:13:35 PM WEST Jean-Marc Lasgouttes wrote:
> Yes, clang 10 does
>
> JMarc
BTW compiling with clang 11 and without changing the compile flags I get lots
(in the tens) of warnings like this:
/home/jamatos/lyx/lyx/src/insets/InsetTabular.h:92:7: warning: definition of
Le 05/10/2020 à 12:26, Yuriy Skalko a écrit :
Yes, I missed these. Now it should be complete. Does Clang agree with me? :)
Yes, clang 10 does :)
JMarc
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Am Mon, 5 Oct 2020 13:26:18 +0300
schrieb Yuriy Skalko :
> > This one is in too.
> >
> > We are almost there :)
> >
> > JMarc
>
> Yes, I missed these. Now it should be complete. Does Clang agree with me? :)
>
> Yuriy
No warnings now concerning 'override' with clang8.0.0
Kornel
> This one is in too.
>
> We are almost there :)
>
> JMarc
Yes, I missed these. Now it should be complete. Does Clang agree with me? :)
Yuriy
From 8f625dd2931ad3a90187c1f70579c614003be87c Mon Sep 17 00:00:00 2001
From: Yuriy Skalko
Date: Mon, 5 Oct 2020 13:22:55 +0300
Subject: [PATCH] Amend
Le 04/10/2020 à 18:18, Yuriy Skalko a écrit :
And now clang++ 10 complains a lot...
And this patch should fix the rest.
This one is in too.
We are almost there :)
JMarc
In file included from ../../../../master/src/frontends/qt/Dialog.cpp:15:
On Sun, Oct 04, 2020 at 07:18:07PM +0300, Yuriy Skalko wrote:
> > And now clang++ 10 complains a lot...
>
> And this patch should fix the rest.
Looks good to me. P
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
> And now clang++ 10 complains a lot...
And this patch should fix the rest.
Yuriy
From 3786af0ec675cab02d48581ac07f97090534e0f3 Mon Sep 17 00:00:00 2001
From: Yuriy Skalko
Date: Sun, 4 Oct 2020 17:56:53 +0300
Subject: [PATCH] Amend efc0877f
Add more `override` specifiers. Replace `throw()` to
> And now clang++ 10 complains a lot...
>
> JMarc
This should fix it. I assume there will be more places...
Yuriy
From dd855c31bcb983ab533d1002ab7515b74ab4b290 Mon Sep 17 00:00:00 2001
From: Yuriy Skalko
Date: Sat, 3 Oct 2020 15:42:14 +0300
Subject: [PATCH] Amend efc0877f
---
Le 03/10/2020 à 13:19, Jean-Marc Lasgouttes a écrit :
Le 02/10/2020 à 19:53, Yuriy Skalko a écrit :
Here is an updated patch.
Yes, there are more places to add the `override`. I'll try to change the
rest on the second step. Is it OK to commit the patch in its current
state?
Thanks a lot. It
Le 02/10/2020 à 19:53, Yuriy Skalko a écrit :
Here is an updated patch.
Yes, there are more places to add the `override`. I'll try to change the
rest on the second step. Is it OK to commit the patch in its current state?
Thanks a lot. It is in now.
JMarc
--
lyx-devel mailing list
> Actually, boost 1.74 only uses override in a handful of cases. Not worth
> updating now.
>
> Therefore, it does not seem doable to use -Wsuggest-override with gcc.
>
> JMarc
This should be useful to disable such warnings from boost:
> I just did that and see that many files have now been handled, probably
> because cppcheck did not warn about Qt headers: GuiView.h, GuiWorkArea.h...
>
>
> Here is a log file for your enjoyment.
>
> I'll try to handle the boost part by updating our local copy to the latest
> version 1.74
Le 02/10/2020 à 15:39, Jean-Marc Lasgouttes a écrit :
Le 02/10/2020 à 15:08, Jean-Marc Lasgouttes a écrit :
A few remarks
* there are places with a double space before 'override'
* it does not make sense to keep 'virtual' when overriding.
Could you fix these issues and make the commit message
Le 02/10/2020 à 15:08, Jean-Marc Lasgouttes a écrit :
A few remarks
* there are places with a double space before 'override'
* it does not make sense to keep 'virtual' when overriding.
Could you fix these issues and make the commit message a bit more
consistent about why we do that?
On my
Le 01/10/2020 à 20:40, Yuriy Skalko a écrit :
Hello,
I've added `override` specifiers into the LyX codebase. This will
improve code maintainability in future. To find overridden methods I've
used the Cppcheck static analyzer. Probably some are missed and should
be marked later.
Jean-Marc
29 matches
Mail list logo
