Previously it happened that these headers in all clients were included after
some other headers that define these types (directly or indirectly).
Oh, I see it's just that we were always lucky to have e.g. include FileName.h
before include Clipboard.h.
Thanks,
Pavel
Yes.
C/C++ header include
On Mon, Oct 26, 2020 at 12:45:53AM +0200, Yuriy Skalko wrote:
> Previously it happened that these headers in all clients were included after
> some other headers that define these types (directly or indirectly).
Oh, I see it's just that we were always lucky to have e.g. include FileName.h
before i
--- a/src/frontends/Clipboard.h
+++ b/src/frontends/Clipboard.h
@@ -14,6 +14,7 @@
#ifndef BASE_CLIPBOARD_H
#define BASE_CLIPBOARD_H
+#include "support/FileName.h"
#include "support/strfwd.h"
namespace lyx {
diff --git a/src/frontends/qt/GuiKeySymbol.h b/src/frontends/qt/GuiKeySymbol.h
in
On Sun, Oct 25, 2020 at 09:09:00AM +0200, Yuriy Skalko wrote:
> --- a/src/frontends/Clipboard.h
> +++ b/src/frontends/Clipboard.h
> @@ -14,6 +14,7 @@
> #ifndef BASE_CLIPBOARD_H
> #define BASE_CLIPBOARD_H
>
> +#include "support/FileName.h"
> #include "support/strfwd.h"
>
> namespace lyx {
>
OK on these.
Riki
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
From eeacba8e112b8af7e5c924ad2cacb1457dc816dd Mon Sep 17 00:00:00 2001
From: Yuriy Skalko
Date: Sun, 25 Oct 2020 00:47:13 +0300
Subject: [PATCH 1/2] Move include of own header to the top. Fix dependencies
---
src/BiblioInfo.cpp | 3 ++-
src/FontInfo.cpp
I am sorry, but this is causing a load of errors on cygwin. I am going
to fix it by using docstring.h instead of strfwd.h where necessary.
The following one is the kind of compile error I get. I am surprised that
it seems to compile fine with mingw, though.
I suppose it compiles because conditi
On Mon, Oct 19, 2020 at 06:14:14PM -0400, Richard Kimberly Heck wrote:
> On 10/19/20 5:52 PM, Yuriy Skalko wrote:
> > The last pass with the assistance from iwyu tool.
>
> Assuming it compiles, it looks fine. Using strfwd.h in various places is
> definitely worth it.
I am sorry, but this is causi
> Assuming it compiles, it looks fine. Using strfwd.h in various places is
> definitely worth it.
>
> Riki
Thanks, committed.
> I guess you checked, but these two below look strange...
> Otherwise looks fine. P
>
>
>> diff --git a/src/Buffer.h b/src/Buffer.h
>> index 2d96ff938e..7d1b5eca97 1
On Mon, Oct 19, 2020 at 06:27:19PM +0300, Yuriy Skalko wrote:
> > Ok, please go on.
> > I am interested to see what will be the output of header_check.sh now :)
> >
> > Pavel
>
> Done. Please share the result of your check when you'll have it.
The current list looks like the attached, most entri
On Tue, Oct 20, 2020 at 12:52:11AM +0300, Yuriy Skalko wrote:
I guess you checked, but these two below look strange...
Otherwise looks fine. P
> diff --git a/src/Buffer.h b/src/Buffer.h
> index 2d96ff938e..7d1b5eca97 100644
> --- a/src/Buffer.h
> +++ b/src/Buffer.h
> @@ -13,6 +13,7 @@
> #define
On 10/19/20 5:52 PM, Yuriy Skalko wrote:
The last pass with the assistance from iwyu tool.
Assuming it compiles, it looks fine. Using strfwd.h in various places is
definitely worth it.
Riki
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
On 10/19/20 5:54 AM, Yuriy Skalko wrote:
If I looked at the correct patch (I do not follow this thread very closely), things
like int const & should definitely be removed from the sources. If they did
compile correctly, then I see no harm in replacing them by 'int' in declarations
and 'int con
The last pass with the assistance from iwyu tool.
Yuriy
From d115ee3dc78c2d72aa081266654dd15b0f5402dc Mon Sep 17 00:00:00 2001
From: Yuriy Skalko
Date: Tue, 20 Oct 2020 00:42:39 +0300
Subject: [PATCH] Clean includes using the output of iwyu tool
---
src/Author.h| 2 +-
src/Bibl
> Ok, please go on.
> I am interested to see what will be the output of header_check.sh now :)
>
> Pavel
Done. Please share the result of your check when you'll have it.
Yuriy
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
On Mon, Oct 19, 2020 at 05:30:28PM +0300, Yuriy Skalko wrote:
> >> Updated patch for cleaning header includes in .cpp files. Is it OK to
> >> apply it now?
> >
> > Does it mean that you're done with the headers :) ?
> > Pavel
>
> Not yet :) I've done with headers after this last patch. If it is O
>> Updated patch for cleaning header includes in .cpp files. Is it OK to
>> apply it now?
>
> Does it mean that you're done with the headers :) ?
> Pavel
Not yet :) I've done with headers after this last patch. If it is OK,
I'll commit the patch for .cpp after this one.
Yuriy
From 18e6e2802acd50
On Mon, Oct 19, 2020 at 12:04:24PM +0300, Yuriy Skalko wrote:
> >> Yes. We'll deal with the rest later.
> >> Pavel
> >
> > The .cpp changing part (for future applying) is in attached patch.
> > Yuriy
>
> Updated patch for cleaning header includes in .cpp files. Is it OK to
> apply it now?
Does
On Mon, Oct 19, 2020 at 11:55:10AM +0300, Yuriy Skalko wrote:
> > All these look good to me, so please go on. Pavel
>
> And here is the next update.
Nice, good to go. Pavel
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
> If I looked at the correct patch (I do not follow this thread very closely),
> things like int const & should definitely be removed from the sources. If
> they did compile correctly, then I see no harm in replacing them by 'int' in
> declarations and 'int const' in implementation of non trivia
Le 19/10/2020 à 11:13, Yuriy Skalko a écrit :
That all is very interesting :) But what will be the decision?
Commit/Add const and commit/Don't commit?
If I looked at the correct patch (I do not follow this thread very
closely), things like int const & should definitely be removed from the
sou
> I guess it may be useful in some places, I would not make that general.
>
> If we want to play with const ther eis Ezst Const :)
> http://slashslash.info/eastconst/
>
> JMarc
That all is very interesting :) But what will be the decision?
Commit/Add const and commit/Don't commit?
Yuriy
--
ly
>> Yes. We'll deal with the rest later.
>> Pavel
>
> The .cpp changing part (for future applying) is in attached patch.
> Yuriy
Updated patch for cleaning header includes in .cpp files. Is it OK to
apply it now?
Yuriy
From 5dc7e176cf02481f0765149cd81693dd8291341d Mon Sep 17 00:00:00 2001
From:
> All these look good to me, so please go on. Pavel
And here is the next update.
Yuriy
From 50f4ab1a4e69346df9bc313ec61e8878852215ef Mon Sep 17 00:00:00 2001
From: Yuriy Skalko
Date: Mon, 19 Oct 2020 11:51:00 +0300
Subject: [PATCH] Reduce includes in header files
---
src/BiblioInfo.h|
Le 16/10/2020 à 22:43, Richard Kimberly Heck a écrit :
Also I cannot remember the usage of `const` for value parameters in any
common C++ library.
I wouldn't know about that. But the same reasons to declare variables
const would seem to apply here, no?
I guess it may be useful in some places
> It is not hard to add `const` again. But here is another important
> question -- consistency. If you look on any function in LyX with int or
> bool parameter, it will be without `const` and still is not modified
> inside the function in 99% cases. I think it is not worth to add it
On 10/16/20 4:26 PM, Yuriy Skalko wrote:
It is probalby worth retaining the 'const' for passing by value. It'd be
meaningless for return values.
Riki
It is not hard to add `const` again. But here is another important
question -- consistency. If you look on any function in LyX with int or
bool
> It is probalby worth retaining the 'const' for passing by value. It'd be
> meaningless for return values.
>
> Riki
It is not hard to add `const` again. But here is another important
question -- consistency. If you look on any function in LyX with int or
bool parameter, it will be without `cons
On 10/16/20 6:11 AM, Pavel Sanda wrote:
On Fri, Oct 16, 2020 at 10:56:02AM +0300, Yuriy Skalko wrote:
And here are new refactoring patches.
The headers are good to go, for const changes I did not followed
much the previous discussion, i.e. not sure whether changes
'int const & p&#x
On Fri, Oct 16, 2020 at 10:56:02AM +0300, Yuriy Skalko wrote:
> And here are new refactoring patches.
The headers are good to go, for const changes I did not followed
much the previous discussion, i.e. not sure whether changes
'int const & p' should not become 'int cost
And here are new refactoring patches.
Yuriy
From 02bd84a72dc9ee134204eee5ce750e8bf107c561 Mon Sep 17 00:00:00 2001
From: Yuriy Skalko
Date: Thu, 15 Oct 2020 12:00:48 +0300
Subject: [PATCH 1/3] Clean math headers
---
src/mathed/MathRow.h| 3 +--
src/mathed/MathStream.h | 1 -
2 files
> All these look good to me, so please go on. Pavel
Committed all.
P.S. Sorry, committed also my local patches. Reverted them immediately.
Yuriy
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
On Thu, Oct 15, 2020 at 10:56:29PM +0300, Yuriy Skalko wrote:
> Here is an update with include cleanup in headers.
All these look good to me, so please go on. Pavel
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
On Thu, Oct 15, 2020 at 07:57:50PM +0300, Yuriy Skalko wrote:
> > 1, 2, 9 are good to go.
>
> Committed these.
>
> > For 8 I do not understand the +#include "insets/Inset.h" part yet.
>
> Since CutAndPaste.h depends on Inset. It was included from Clipboard.h,
> that includes it from Cursor.h, th
Here is an update with include cleanup in headers.
Yuriy
From 677ae51c11b1441cc4e1cb616d5fef42c691 Mon Sep 17 00:00:00 2001
From: Yuriy Skalko
Date: Thu, 15 Oct 2020 21:09:21 +0300
Subject: [PATCH 1/3] Move Cursor.h from TocWidget.h
---
src/frontends/qt/TocWidget.cpp | 1 +
src/frontends/q
> 1, 2, 9 are good to go.
Committed these.
> For 8 I do not understand the +#include "insets/Inset.h" part yet.
Since CutAndPaste.h depends on Inset. It was included from Clipboard.h,
that includes it from Cursor.h, that includes it from DocIterator.h,
that includes it from CursorSlice.h that in
On Thu, Oct 15, 2020 at 10:14:50AM +0300, Yuriy Skalko wrote:
> > Agreed. Unfortunately I suspect that we can achive this only by manually
> > going through the suspects proposed by some tools instead of just
> > taking their results.
>
> Here are manual cleaning of some headers is separate patche
> Agreed. Unfortunately I suspect that we can achive this only by manually
> going through the suspects proposed by some tools instead of just
> taking their results.
Here are manual cleaning of some headers is separate patches. But I
don't think I'll be able to process all the headers.
>> And no
On Wed, Oct 14, 2020 at 03:43:40PM +0300, Yuriy Skalko wrote:
> > Are we trying to make it
> >
> > - "semantically correct", by which I mean removing includes unrelated to
> >the content of the processed file (i.e. forgotten header which is no
> >more used becase the code using it is gone)
On Wed, Oct 14, 2020 at 12:41:19PM +0200, Pavel Sanda wrote:
> Right now I am after the 'suspicious' lines which suggest that include
> might be moved from header to .cpp.
I am done with those now.
I left these three:
suspicious: ./frontends/qt/qt_helpers.h::#include "support/qstring_helpers.h"
su
> If we are going after redundant includes we should first decide what's
> the goal and why we are doing it.
>
> Are we trying to make it
>
> - "semantically correct", by which I mean removing includes unrelated to
>the content of the processed file (i.e. forgotten header which is no
>mor
On Tue, Oct 13, 2020 at 11:41:28PM +0200, Pavel Sanda wrote:
> The real "forgotten" includes which would trigger compiler analysis could
> make difference
> but I am afraid you would need to manually check each include of this type.
>
> If we prefer kicking out any unnecessary header there is alr
On Wed, Oct 14, 2020 at 09:39:36AM +0100, José Abílio Matos wrote:
> You are right in your analysis (also for the part that I did not quoted here).
> The problem is, of course, the include system that was inherited from C and
> the C++ modules that are not here yet. Although the modules are part o
On Tuesday, October 13, 2020 10:41:28 PM WEST Pavel Sanda wrote:
> And then there is somewhat separate issue about generic system headers which
> sometimes land in the code because someone brave enough tried to run it on
> solaris or haiku or god knows what. Here I would be more conservative, and
>
On Tue, Oct 13, 2020 at 11:40:51AM -0400, Richard Kimberly Heck wrote:
> On 10/13/20 3:09 AM, Yuriy Skalko wrote:
> >> Yes. We'll deal with the rest later.
> >> Pavel
> > Done at 2a594d3.
> >
> > The .cpp changing part (for future applying) is in attached patch.
>
> Suggestion: Let's see if we ca
On 10/13/20 1:52 PM, José Abílio Matos wrote:
>
> On Tuesday, October 13, 2020 4:40:51 PM WEST Richard Kimberly Heck wrote:
>
> > Suggestion: Let's see if we can get people on different platforms and
>
> > with different compilers to try the patch. As has already been said, we
>
> > do occasionally
On Tuesday, October 13, 2020 4:40:51 PM WEST Richard Kimberly Heck wrote:
> Suggestion: Let's see if we can get people on different platforms and
> with different compilers to try the patch. As has already been said, we
> do occasionally run into cases where includes are needed sometimes but
> not
Am Tue, 13 Oct 2020 11:40:51 -0400
schrieb Richard Kimberly Heck :
> On 10/13/20 3:09 AM, Yuriy Skalko wrote:
> >> Yes. We'll deal with the rest later.
> >> Pavel
> > Done at 2a594d3.
> >
> > The .cpp changing part (for future applying) is in attached patch.
>
> Suggestion: Let's see if we c
On 10/13/20 3:09 AM, Yuriy Skalko wrote:
>> Yes. We'll deal with the rest later.
>> Pavel
> Done at 2a594d3.
>
> The .cpp changing part (for future applying) is in attached patch.
Suggestion: Let's see if we can get people on different platforms and
with different compilers to try the patch. As h
> Yes. We'll deal with the rest later.
> Pavel
Done at 2a594d3.
The .cpp changing part (for future applying) is in attached patch.
Yuriy
From 87bce97a51b505b6447c50e07574de04964927c2 Mon Sep 17 00:00:00 2001
From: Yuriy Skalko
Date: Mon, 12 Oct 2020 15:30:07 +0300
Subject: [PATCH] Remove dupli
On Mon, Oct 12, 2020 at 11:38:33PM +0300, Yuriy Skalko wrote:
> > I propose to apply only changes to headers for now. I will
> > try to revive my old scripts which will try to remove unnecessary
> > includes in headers first. Only then we look on .cpp files.
>
> So, if I remove include changing in
> I propose to apply only changes to headers for now. I will
> try to revive my old scripts which will try to remove unnecessary
> includes in headers first. Only then we look on .cpp files.
So, if I remove include changing in .cpp from patch, then it can be
committed for now?
Yuriy
--
lyx-devel
On Mon, Oct 12, 2020 at 10:36:36PM +0300, Yuriy Skalko wrote:
> > Getting rid of unnecessary includes is a valuable goal.
> > There are two things to keep in mind:
> > - One should try to get rid of redundant includes from headers first, only
> > after that reducing .cpp files (otherwise the check
> Getting rid of unnecessary includes is a valuable goal.
> There are two things to keep in mind:
> - One should try to get rid of redundant includes from headers first, only
> after that reducing .cpp files (otherwise the check of .h files becomes more
> tricky).
> - some generic headers were in
On Mon, Oct 12, 2020 at 05:26:03PM +0200, Jean-Marc Lasgouttes wrote:
> Le 12/10/2020 ?? 15:51, Pavel Sanda a écrit :
> >Getting rid of unnecessary includes is a valuable goal.
> >There are two things to keep in mind:
> >- One should try to get rid of redundant includes from headers first, only
>
Le 12/10/2020 à 15:51, Pavel Sanda a écrit :
Getting rid of unnecessary includes is a valuable goal.
There are two things to keep in mind:
- One should try to get rid of redundant includes from headers first, only
after that reducing .cpp files (otherwise the check of .h files becomes more
tric
Le 12/10/2020 à 15:51, Pavel Sanda a écrit :
On Mon, Oct 12, 2020 at 03:33:45PM +0300, Yuriy Skalko wrote:
The 1-3 patches look fine.
They are in now.
JMarc
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
On Mon, Oct 12, 2020 at 03:33:45PM +0300, Yuriy Skalko wrote:
The 1-3 patches look fine.
> From 7081d5c9f2e441fdce68d672fd07da6f1c121bfc Mon Sep 17 00:00:00 2001
> From: Yuriy Skalko
> Date: Mon, 12 Oct 2020 15:30:07 +0300
> Subject: [PATCH 4/4] Remove unused forward declarations and header incl
I've continued with refactoring of LyX codebase. Here are my new patches.
Yuriy
From 942ddea047c807b1f0fed82f089847be6543ddaa Mon Sep 17 00:00:00 2001
From: Yuriy Skalko
Date: Fri, 9 Oct 2020 18:50:24 +0300
Subject: [PATCH 1/4] Constify
---
src/Counters.cpp| 2 +-
src/Counters.
59 matches
Mail list logo
