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