www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Help needed with libdparse PR

reply RazvanN <razvan.nitu1305 gmail.com> writes:
Hello everyone!

I have made a PR to add alias assign recognition in libdparse 
[1]. This is done to unblock a series of PRs (e.g [2]) in phobos 
that currently are blocked by the style checker (that uses 
libdparse). However, mt PR is blocked because libdparse uses an 
old version of stdx.allocator. Is there anyone who could provide 
pointers on how to bump the version of stdx.allocator to better 
one?

Cheers,
RazvanN

[1] https://github.com/dlang-community/libdparse/pull/441
[2] https://github.com/dlang/phobos/pull/8047
May 17 2021
parent reply Basile B. <b2.temp gmx.com> writes:
On Monday, 17 May 2021 at 08:36:23 UTC, RazvanN wrote:

 Hello everyone!

 I have made a PR to add alias assign recognition in libdparse 
 [1]. This is done to unblock a series of PRs (e.g [2]) in 
 phobos that currently are blocked by the style checker (that 
 uses libdparse). However, mt PR is blocked because libdparse 
 uses an old version of stdx.allocator. Is there anyone who 
 could provide pointers on how to bump the version of 
 stdx.allocator to better one?

 Cheers,
 RazvanN

 [1] https://github.com/dlang-community/libdparse/pull/441
 [2] https://github.com/dlang/phobos/pull/8047


I strongly suggest you to disable the Meson tests. Meson support 
was occasionally a source of friction [1] when I contributed to 
dlang-community. This is enough now. Those who care about this 
alternative build system will have to come and fix the support.

The problem in the present case is also that libdparse-based 
tools use all a special branch of stdx-alloc (2.77.z) to prevent 
the dep on mir-core but right now the meson stuff for the latest 
tag dont match (git tag 2.77.5, meson tag 2.77.2).

[1] : 
https://forum.dlang.org/post/jelnczcitltgfolwogjf forum.dlang.org
May 17 2021
next sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Monday, 17 May 2021 at 09:02:17 UTC, Basile B. wrote:

 [snip]

 The problem in the present case is also that libdparse-based 
 tools use all a special branch of stdx-alloc (2.77.z) to 
 prevent the dep on mir-core but right now the meson stuff for 
 the latest tag dont match (git tag 2.77.5, meson tag 2.77.2).

 [1] : 
 https://forum.dlang.org/post/jelnczcitltgfolwogjf forum.dlang.org


It is currently pulling mir-core less than 0.3.0, which has a 
Boost License. Why not just copy the needed mir-core stuff 
directly into it?
May 17 2021
prev sibling parent reply drug <drug2004 bk.ru> writes:
17.05.2021 12:02, Basile B. пишет:

 The problem in the present case is also that libdparse-based tools use 
 all a special branch of stdx-alloc (2.77.z) to prevent the dep on 
 mir-core 


What's wrong with mir-core?
May 17 2021
parent reply Basile B. <b2.temp gmx.com> writes:
On Monday, 17 May 2021 at 10:05:27 UTC, drug wrote:

 17.05.2021 12:02, Basile B. пишет:

 The problem in the present case is also that libdparse-based 
 tools use all a special branch of stdx-alloc (2.77.z) to 
 prevent the dep on mir-core


 What's wrong with mir-core?


That's actually another option, drop the 2.77.z branch of stdx 
alloc.
(forgot to say, its possible that it requires a backport from the 
master branch...)

But is it for dparse so dscanner, dcd, dsymbol, dfmt will have to 
be updated.
That's some boring maintenance work.

Currently there's nothing that can be done with a simple PR, I've 
tried a few days ago:

- https://github.com/dlang-community/libdparse/pull/444
- https://github.com/dlang-community/libdparse/pull/443
- https://github.com/dlang-community/libdparse/pull/442

For the time being, disable the Meson tests, that's what blocks 
the PR, that what's urgent.

Then, later, those who still care about the projects involved 
could take a decision on : "fix the tags in the 2.77.z branch or 
update everything to use master".
May 17 2021
parent reply RazvanN <razvan.nitu1305 gmail.com> writes:
On Monday, 17 May 2021 at 10:37:01 UTC, Basile B. wrote:

 On Monday, 17 May 2021 at 10:05:27 UTC, drug wrote:

 [...]


 That's actually another option, drop the 2.77.z branch of stdx 
 alloc.
 (forgot to say, its possible that it requires a backport from 
 the master branch...)

 [...]


Done: https://github.com/dlang-community/libdparse/pull/441/ . 
Thanks for the suggestion. Everything passes now.
May 20 2021
parent reply WebFreak001 <d.forum webfreak.org> writes:
On Thursday, 20 May 2021 at 11:12:29 UTC, RazvanN wrote:

 On Monday, 17 May 2021 at 10:37:01 UTC, Basile B. wrote:

 On Monday, 17 May 2021 at 10:05:27 UTC, drug wrote:

 [...]


 That's actually another option, drop the 2.77.z branch of stdx 
 alloc.
 (forgot to say, its possible that it requires a backport from 
 the master branch...)

 [...]


 Done: https://github.com/dlang-community/libdparse/pull/441/ . 
 Thanks for the suggestion. Everything passes now.


For the D-Scanner update an update of libdparse to libddoc is 
needed (because otherwise incompatible version specification)

I would have 2 solutions for that:
- allow any libdparse version (maybe up to some certain point 
like 1.0.0), because only tokenization is used anyway
- have a `common` submodule, which doesn't require libdparse (as 
D-Scanner doesn't care if the embedded code is highlighted and 
makes it more stable)

I have opened a PR actually implementing both because I can see 
with the `common` submodule that either the libdparse version 
will be locked to something working by the user, or only the 
`common` submodule is used.

Anyone want to review that PR or do you think we should first 
continue as usual and add another release just bumping libdparse 
once again?
May 20 2021
next sibling parent WebFreak001 <d.forum webfreak.org> writes:
On Thursday, 20 May 2021 at 17:13:47 UTC, WebFreak001 wrote:

 [...]


PR in question: https://github.com/dlang-community/libddoc/pull/54
May 20 2021
prev sibling parent RazvanN <razvan.nitu1305 gmail.com> writes:
On Thursday, 20 May 2021 at 17:13:47 UTC, WebFreak001 wrote:

 On Thursday, 20 May 2021 at 11:12:29 UTC, RazvanN wrote:

 On Monday, 17 May 2021 at 10:37:01 UTC, Basile B. wrote:

 On Monday, 17 May 2021 at 10:05:27 UTC, drug wrote:

 [...]









 Anyone want to review that PR or do you think we should first 
 continue as usual and add another release just bumping 
 libdparse once again?


Dscanner depends on both libbdoc and libdparse so it looks like 
the version of libdparse needs to be bumped anyway, no?

I see that the PR has been merged. What are the next steps?
May 20 2021