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?

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

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.

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?

On Thursday, 20 May 2021 at 17:13:47 UTC, WebFreak001 wrote:
> [...]

PR in question: https://github.com/dlang-community/libddoc/pull/54

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?