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
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
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
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
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
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
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
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
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