Closed spikespaz closed 6 years ago
That's the price for catching errors... They're treated as "internal errors" as I don't know what exactly went wrong. But I'm thinking that today or tomorrow I'm going to upgrade libdparse and add a workaround for the CI to pass even of there's going to be a dependency conflict.
Because, to be honest, I'm also starting to get fed up with libdparse errors...
I disabled the option in my settings to see what the issue was, but it still displays nothing. Is there maybe something that you forgot to block conditionally, and it blocks even if that steamroll option isn't enabled?
I don't know, the crashes can be somewhat unpredictable. Usually libdparse 0.8.x crashes when you have a function without a body, yet sometimes it doesn't crash when writing a new function. It could have to do with how VSCose decides to send file changes to DLS.
Maybe this is the issue?
$ dub build dls --force
Building package dls in C:\Users\spike\AppData\Local\dub\packages\dls-0.14.3\dls\
Running pre-generate commands for dcd...
Running pre-generate commands for dls:i18n...
Running pre-generate commands for dscanner...
Running pre-generate commands for dls...
The system cannot find the path specified.
Command failed with exit code 1: dub describe --quiet > data/description.json
Did you get that after manually upgrading the dependencies? Or without changing anything?
Just dub fetch
ed it first, nothing else.
What happens if you dub describe
manually?
It's fixed... What??
First off, what went wrong in the first place. Second, why did that need to happen now and never before?
If you look at any of the Travis builds using dmd, you'll see that the first attempt at compiling results in a linker error. After that however, it builds fine, just by doing dub build
a second time.
On Windows, on my machine, on the first build after booting, most of the time dub will tell me that the pregenerate command for dscanner failed, and the next builds are all fine.
My conclusion is: some things are just weird beyond comprehension. and I've stopped wondering about them...
With v0.15.0, I now build with --nodeps
after automatically fetching all dependencies in a script, which means I can control dependencies manually without worrying about conflicts. (and thus upgrade dcd, dscanner, dsymbol and libdparse)
Awesome, thanks!
Can DUB fetch from the master branch of the repo?
You mean to fetch the master branch of dfmt ? While it's possible to use ~master
, not only is it deprecated, but it also makes the build not reproducible. I want to stay as far away from this as possible.
No, not for you, for me. That is a stupid idea. I wanted to use 0.15 but I guess the VS Code side needs to be updated first?
I couldn't figure out something like dub fetch dls --version=master
so I just cloned and compiled it, set the path in VS Code. I would assume I'm jumping on it too fast, it isn't supposed to work?
[Error - 5:38:57 AM] Starting client failed
Error: Unsupported server configuration {
"command": ""
}
at _getServerWorkingDir.then.serverWorkingDir (C:\Users\spike\.vscode\extensions\laurenttreguier.vscode-dls-1.10.3\node_modules\vscode-languageclient\lib\main.js:362:35)
at <anonymous>
Never mind that stupid new graphical editor in VS Code was formatting the settings JSON wrong. Works like a charm.
Phew. I feared there was yet again a problem with how the VSCode extension handled the path... The v0.15.0 binaries are compiled and will be picked up soon enough anyway.
Just a notification. And that's it. Nothing in output console.
VS Code 1.18.1.