www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DScanner 0.12.1 stopped working

reply Carsten Schlote <carsten.schlote gmx.net> writes:
HI together,

it seems that dscanner started to fail recently, and at work some 
of our CI pipelines stopped working. I would care less, if this 
would have happed at home. But at work this opens more questions 
about the usability of dlang - for whatever purpose. So any help 
to solve this issue asap would be appreciated.

Error output:
```
.dub/packages/dscanner-0.12.1/dscanner/src/dscanner/analysis/helpers.d(59,32):
Error: none of the overloads of `this` are callable using argument types
`(CAllocatorImpl!(Mallocator, Flag.no))`
...
```

Is there any information available, what is causing this problem 
and how to fix it?

It happens with the latest versions of DMD and LDC2. Also it 
breaks with GDC, but GDC is not up to date. It worked before, so 
I suspect some changes in packages DScanner depends on.
Jul 05 2022
parent reply Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Tuesday, 5 July 2022 at 08:18:49 UTC, Carsten Schlote wrote:

 HI together,

 it seems that dscanner started to fail recently, and at work 
 some of our CI pipelines stopped working. I would care less, if 
 this would have happed at home. But at work this opens more 
 questions about the usability of dlang - for whatever purpose. 
 So any help to solve this issue asap would be appreciated.

 Error output:
 ```
 .dub/packages/dscanner-0.12.1/dscanner/src/dscanner/analysis/helpers.d(59,32):
Error: none of the overloads of `this` are callable using argument types
`(CAllocatorImpl!(Mallocator, Flag.no))`
 ...
 ```

 Is there any information available, what is causing this 
 problem and how to fix it?

 It happens with the latest versions of DMD and LDC2. Also it 
 breaks with GDC, but GDC is not up to date. It worked before, 
 so I suspect some changes in packages DScanner depends on.


Probably is not what you are searching for, but D-Scanner master 
is building on my machine with this dub.selections.json


    {
	"fileVersion": 1,
	"versions": {
		"dsymbol": "0.13.0",
		"emsi_containers": "0.8.1",
		"inifiled": "1.3.3",
		"libddoc": "0.8.0",
		"libdparse": "0.19.1",
		"stdx-allocator": "2.77.5"
	}
    }
Jul 05 2022
parent reply Carsten Schlote <carsten.schlote gmx.net> writes:
On Tuesday, 5 July 2022 at 08:30:29 UTC, Paolo Invernizzi wrote:

 Probably is not what you are searching for, but D-Scanner 
 master is building on my machine with this dub.selections.json


    {
 	"fileVersion": 1,
 	"versions": {
 		"dsymbol": "0.13.0",
 		"emsi_containers": "0.8.1",
 		"inifiled": "1.3.3",
 		"libddoc": "0.8.0",
 		"libdparse": "0.19.1",
 		"stdx-allocator": "2.77.5"
 	}
    }


Thanks alot. Exactly what is needed.

I changed my dub.selection file to your setup, and DScanner 
nicely compiled. This is, what I had to change:

```
$ diff  dub.selections.json dub.selections.json~
4c4
< 		"dsymbol": "0.13.0",
---

 		"dsymbol": "0.13.2",


8c8
< 		"libdparse": "0.19.1",
---

 		"libdparse": "0.19.3",


```
So, either dsymbol or libdparse did some incompatible change, 
despite the fact that the version number (SemVer?) just bumped 
the build number, but neither Majaor/Minor numbers.

Later I will work out, which of the two modules is causing the 
problem. Maybe this helps to track down the reason for this 
problem.
Jul 05 2022
next sibling parent reply RazvanN <razvan.nitu1305 gmail.com> writes:
On Tuesday, 5 July 2022 at 09:53:29 UTC, Carsten Schlote wrote:

 On Tuesday, 5 July 2022 at 08:30:29 UTC, Paolo Invernizzi wrote:

    [...]


 Thanks alot. Exactly what is needed.

 I changed my dub.selection file to your setup, and DScanner 
 nicely compiled. This is, what I had to change:

 ```
 $ diff  dub.selections.json dub.selections.json~
 4c4
 < 		"dsymbol": "0.13.0",
 ---

 [...]


 8c8
 < 		"libdparse": "0.19.1",
 ---

 [...]


 ```
 So, either dsymbol or libdparse did some incompatible change, 
 despite the fact that the version number (SemVer?) just bumped 
 the build number, but neither Majaor/Minor numbers.

 Later I will work out, which of the two modules is causing the 
 problem. Maybe this helps to track down the reason for this 
 problem.


It's probably libdparse since dsymbol depends on it. It's 
probably this PR that did it: 
https://github.com/dlang-community/libdparse/pull/463
Jul 05 2022
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 7/5/22 8:09 AM, RazvanN wrote:

 On Tuesday, 5 July 2022 at 09:53:29 UTC, Carsten Schlote wrote:

 On Tuesday, 5 July 2022 at 08:30:29 UTC, Paolo Invernizzi wrote:

    [...]


 Thanks alot. Exactly what is needed.

 I changed my dub.selection file to your setup, and DScanner nicely 
 compiled. This is, what I had to change:

 ```
 $ diff  dub.selections.json dub.selections.json~
 4c4
 <         "dsymbol": "0.13.0",
 ---

 [...]


 8c8
 <         "libdparse": "0.19.1",
 ---

 [...]


 ```
 So, either dsymbol or libdparse did some incompatible change, despite 
 the fact that the version number (SemVer?) just bumped the build 
 number, but neither Majaor/Minor numbers.

 Later I will work out, which of the two modules is causing the 
 problem. Maybe this helps to track down the reason for this problem.


 
 It's probably libdparse since dsymbol depends on it. It's probably this 
 PR that did it: https://github.com/dlang-community/libdparse/pull/463


The problem is that dscanner uses stdx.allocator, but libdparse was 
switched to using std.experimental.allocator in that PR.

The result is that you can't pass an allocator from one lib to the 
other, because they are from different modules.

There is a way to fix this: change libdparse to use stdx.allocator when 
some other project has included it (this can be done with an optional 
dependency specification).

-Steve
Jul 05 2022
parent jmh530 <john.michael.hall gmail.com> writes:
On Tuesday, 5 July 2022 at 15:22:57 UTC, Steven Schveighoffer 
wrote:

 [snip]
 There is a way to fix this: change libdparse to use 
 stdx.allocator when some other project has included it (this 
 can be done with an optional dependency specification).

 -Steve


Or finalize and then merge std.experimental.allocator...
Jul 05 2022
prev sibling parent reply bauss <jj_1337 live.dk> writes:
On Tuesday, 5 July 2022 at 09:53:29 UTC, Carsten Schlote wrote:

 Later I will work out, which of the two modules is causing the 
 problem. Maybe this helps to track down the reason for this 
 problem.


Both. dsymbol is a part of libdparse.
Jul 05 2022
parent reply Carsten Schlote <carsten.schlote gmx.net> writes:
On Tuesday, 5 July 2022 at 12:09:39 UTC, bauss wrote:

 On Tuesday, 5 July 2022 at 09:53:29 UTC, Carsten Schlote wrote:

 Later I will work out, which of the two modules is causing the 
 problem. Maybe this helps to track down the reason for this 
 problem.


 Both. dsymbol is a part of libdparse.


So the question should be, why a breaking change slipped into 
mainline. At least it is impossible to build the dub package now 
with any of the current compilers.

Maybe the CI pipeline should also build with the latest 
dependancies. OR put the dub.selections file under revision 
control, so that code like

dub fetch dscanner
dub run dscanner -- ...

will properly compile and work. Without breaking the build....
Jul 05 2022
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 06/07/2022 12:56 AM, Carsten Schlote wrote:

 So the question should be, why a breaking change slipped into mainline. 
 At least it is impossible to build the dub package now with any of the 
 current compilers.


What happened is that WebFreak created the tag v0.19.3 which is 
automatically upgraded to. Rather than v0.20.0 which wouldn't have been.
Jul 05 2022
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 7/5/22 1:30 PM, rikki cattermole wrote:

 
 On 06/07/2022 12:56 AM, Carsten Schlote wrote:

 So the question should be, why a breaking change slipped into 
 mainline. At least it is impossible to build the dub package now with 
 any of the current compilers.


 
 What happened is that WebFreak created the tag v0.19.3 which is 
 automatically upgraded to. Rather than v0.20.0 which wouldn't have been.


Nope.

https://github.com/dlang-community/D-Scanner/blob/e639f8bcbe8a73c9ebefb445edc101ec0c2731c1/dub.json#L15

-Steve
Jul 05 2022
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 06/07/2022 5:48 AM, Steven Schveighoffer wrote:

 On 7/5/22 1:30 PM, rikki cattermole wrote:

 On 06/07/2022 12:56 AM, Carsten Schlote wrote:

 So the question should be, why a breaking change slipped into 
 mainline. At least it is impossible to build the dub package now with 
 any of the current compilers.


 What happened is that WebFreak created the tag v0.19.3 which is 
 automatically upgraded to. Rather than v0.20.0 which wouldn't have been.


 
 Nope.
 
 https://github.com/dlang-community/D-Scanner/blob/e639f8bcbe8a73c9ebefb445edc101ec0
2731c1/dub.json#L15 
 
 
 -Steve


"libdparse": ">=0.19.2 <1.0.0",
"dsymbol" : ">=0.13.0 <1.0.0",


 Restrict to a certain minor version: "~>2.2.13", equivalent to 


">=2.2.13 <2.3.0"

That sneaky < condition at the end is more broad than what ~> is.
Jul 05 2022
parent reply Carsten Schlote <carsten.schlote gmx.net> writes:
On Tuesday, 5 July 2022 at 17:52:37 UTC, rikki cattermole wrote:

 "libdparse": ">=0.19.2 <1.0.0",
 "dsymbol" : ">=0.13.0 <1.0.0",


 Restrict to a certain minor version: "~>2.2.13", equivalent


 to ">=2.2.13 <2.3.0"

 That sneaky < condition at the end is more broad than what ~> 
 is.


The current breaking change should bump the mayor number.

The minor number should mark backward compatible changes.

And the last digit should be bumped for all bugfixes, cleanups 
and other stuff, which does NOT change the API at all (except of 
fixing it).

But even when we would use proper rules, it still depends on 
properly setting up the new SemVer tags for Dub modules. Any 
mistake on this will probaly break the code.
Jul 05 2022
next sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 7/5/22 2:47 PM, Carsten Schlote wrote:

 On Tuesday, 5 July 2022 at 17:52:37 UTC, rikki cattermole wrote:

 "libdparse": ">=0.19.2 <1.0.0",
 "dsymbol" : ">=0.13.0 <1.0.0",


 Restrict to a certain minor version: "~>2.2.13", equivalent


 to ">=2.2.13 <2.3.0"

 That sneaky < condition at the end is more broad than what ~> is.


 
 The current breaking change should bump the mayor number.
 
 The minor number should mark backward compatible changes.
 
 And the last digit should be bumped for all bugfixes, cleanups and other 
 stuff, which does NOT change the API at all (except of fixing it).
 
 But even when we would use proper rules, it still depends on properly 
 setting up the new SemVer tags for Dub modules. Any mistake on this will 
 probaly break the code.
 
 


I don't know the context of how it's used, but changing allocators from 
stdx.allocator to std.experimental.allocator might be considered by some 
as not a breaking change.

D has a nasty habit of making everything a breaking change, because 
introspection is so good. So you have to draw the line somewhere. I 
haven't looked in depth at it, but if dscanner is using things that are 
implementation details, there is an argument to say that dscanner is the 
one that strayed from the public API.

But like I said, it can be fixed by making stdx.allocator an optional 
dependency of libdparse.

-Steve
Jul 05 2022
parent reply singingbush <singingbush hotmail.com> writes:
On Tuesday, 5 July 2022 at 19:03:03 UTC, Steven Schveighoffer 
wrote:

 On 7/5/22 2:47 PM, Carsten Schlote wrote:

 I don't know the context of how it's used, but changing 
 allocators from stdx.allocator to std.experimental.allocator 
 might be considered by some as not a breaking change.

 D has a nasty habit of making everything a breaking change, 
 because introspection is so good. So you have to draw the line 
 somewhere. I haven't looked in depth at it, but if dscanner is 
 using things that are implementation details, there is an 
 argument to say that dscanner is the one that strayed from the 
 public API.

 But like I said, it can be fixed by making stdx.allocator an 
 optional dependency of libdparse.

 -Steve


I've been hurt numerous times over the years by breaking changes 
in D so started maintaining a list of version checks that have 
been helpful in keeping projects compile with multiple language 
versions.

https://gist.github.com/SingingBush/3a2a6d2a41a81c1bafb26e5f69f823c0

It would be great if more packages in dub repo used such 
mechanisms.
Jul 06 2022
parent reply jmh530 <john.michael.hall gmail.com> writes:
On Wednesday, 6 July 2022 at 18:37:45 UTC, singingbush wrote:

 [snip]

 I've been hurt numerous times over the years by breaking 
 changes in D so started maintaining a list of version checks 
 that have been helpful in keeping projects compile with 
 multiple language versions.

 https://gist.github.com/SingingBush/3a2a6d2a41a81c1bafb26e5f69f823c0

 It would be great if more packages in dub repo used such 
 mechanisms.


Have you made use of toolchain requirements?
https://dub.pm/package-format-sdl.html#toolchain-requirements
Jul 06 2022
parent singingbush <singingbush hotmail.com> writes:
On Wednesday, 6 July 2022 at 19:02:05 UTC, jmh530 wrote:

 On Wednesday, 6 July 2022 at 18:37:45 UTC, singingbush wrote:

 [snip]

 I've been hurt numerous times over the years by breaking 
 changes in D so started maintaining a list of version checks 
 that have been helpful in keeping projects compile with 
 multiple language versions.

 https://gist.github.com/SingingBush/3a2a6d2a41a81c1bafb26e5f69f823c0

 It would be great if more packages in dub repo used such 
 mechanisms.


 Have you made use of toolchain requirements?
 https://dub.pm/package-format-sdl.html#toolchain-requirements


Yes but that's about limiting which compilers are supported. 
While that's helpful it's not the same thing. Checking for 
language level in code or the existence of some package allows 
for different approaches to be used and therefore expand 
compatibility.
Jul 06 2022
prev sibling parent reply Guillaume Piolat <first.last example.com> writes:
On Tuesday, 5 July 2022 at 18:47:59 UTC, Carsten Schlote wrote:

 The current breaking change should bump the mayor number.

 The minor number should mark backward compatible changes.

 And the last digit should be bumped for all bugfixes, cleanups 
 and other stuff, which does NOT change the API at all (except 
 of fixing it).


<rant>

One should almost always subscribe to non-breaking change, doing:

     ~>x.0       => it means   ">=x.0.0 <x+1.0.0"

The above is exactly what you want.
This should never happen:

     ~>x.y.z.  => just say NO

Breaking changes require MAJOR version bump.
DUB suggesting the faulty version doesn't help.
Use `~>x.0`.
Jul 07 2022
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 7 July 2022 at 12:37:13 UTC, Guillaume Piolat wrote:

 Breaking changes require MAJOR version bump.
 DUB suggesting the faulty version doesn't help.
 Use `~>x.0`.


Version 0.x are pre release (gamma), so they can break at any 
time?

You should not use version 0.x in production at all, but some D 
libs stay on 0.x forever...
Jul 09 2022