VSCode extension testing: Use `vscode.executeDefinitionProvider` in test - visual-studio-code

Background
I'm trying to auto-test my VSCode extension. The extension works with python files and uses vscode.executeDefinitionProvider and vscode.executeDocumentSymbolProvider on them.
Problem
vscode.executeDefinitionProvider always returns [], vscode.executeDocumentSymbolProvider always returns undefined.
Notes
When running the same code in a debug session of the extension (no test session), the commands work flawless.
I ensured the extensions to be available during the test and even manually activated them with
let ext = vscode.extensions.getExtension("ms-python.python");
assert.notStrictEqual (ext, undefined);
await ext?.activate ();
ext = vscode.extensions.getExtension("ms-python.vscode-pylance");
assert.notStrictEqual (ext, undefined);
await ext?.activate ();
Question
How do I get the commands to succeed during automated test.
Edit: Workaround
Apparently VSCode takes its time to really activate the extensions. I could get it working placing a await sleep (10000); in index.ts::run () before return new Promise((c, e) => {.
While this is working, it's a really unstable workaround, Is there any way to make the code wait until the whole environment is fully loaded?

In the end nothing really stably worked for me, so I resorted to the following (perfectly fine working) solution.
My auto tests are run from the productive environment, like any other extension.
In package.json I created a new command _test.
the command would run ./test/suite/index.ts : run().

Extension<T>::activate(): Thenable<T>
Returns: Thenable<T> - A promise that will resolve when this extension has been activated.
await ext?.activate();

Related

mason lsp pyright seems to be download but dosen't work on vim

I have a problem on my nvim LSP.
according to mason plugin the pyright is downloaded and I on other IDE the lsp works great.
when i open python file with neovim it didn't recognized import and basic functions.
someone can handle this situation?
maybe it's because Lspinfo tell me that it didn't get the python root directory?import don't auto complete pythonpyright is downloaded via masonLSPInfo description
on other languages it works so don't really understand the problem
Same as me, at the moment I solved like this (it happens in some languages for me too):
local status_ok, mason = pcall(require, "mason")
if not status_ok then
return
end
local status_masonlsp_ok, mason_lspconfig = pcall(require, "mason-lspconfig")
if not status_masonlsp_ok then
return
end
local servers = {
"sumneko_lua",
"rust_analyzer",
"tailwindcss",
"bashls",
"pyright",
-- "csharp_ls",
"html",
"omnisharp",
"gopls",
}
mason.setup(settings)
mason_lspconfig.setup({
ensure_installed = servers,
automatic_installation = true,
})
So when I open nvim they are installed automatically.

parcel watch only detects first file change

I have the following in ./js/parcel/build-js.js (it is more or less a simplification of exactly what the API docs example does, except that it takes an optional --watch argument):
#!/usr/bin/env node
const Bundler = require('parcel-bundler');
const path = require('path');
const watch = process.argv.indexOf('--watch') > 0;
if (watch) console.log('Watching files...');
(async function bundleJs() {
const jsBundler = new Bundler(path.join(__dirname, '../src/common.js'), {
watch,
hmr: false,
});
jsBundler.on('bundled', () => {
console.log('bundled!');
});
const bundle = await jsBundler.bundle();
console.log('done');
})();
When I run node js/parcel/build-js.js --watch, it detects the first change to src/common.js and prints:
Watching files...
✨ Built in 585ms.
bundled!
done
This is as I'd expect. When I edit and save src/common.js, it sees that and then the total output becomes (done gets deleted):
Watching files...
✨ Built in 585ms.
bundled!
✨ Built in 86ms.
bundled!
But after that, no file changes are detected. I make changes and save but it just sits there, producing no more output or updating the build. Why only once?
Note: If I do strace node js/parcel/build-js.js --watch, it seems to just sit on an unfinished epoll_wait(3,, which I guess means it's waiting for something, but maybe watching the wrong file...
Edit: Versions!
parcel-bundler: 1.12.3
node: 10.15.1
Ubuntu 18.04
Edit: using parcel watch
This appears to be a system-wide thing for me. I did yarn globals add parcel (which also installed 1.12.3), and now watching any JS file with parcel watch path/to/file.js does the same thing.
It turned out to be a conflict between Parcel's change detection and the default Vim setup. From the Hot Module Replacement docs:
Some text editors and IDE's have a feature called safe write that basically prevents data loss, by taking a copy of the file and renaming it when saved.
When using Hot Module Reload (HMR) this feature blocks the automatic detection of file updates, to disable safe write use the options provided below:
I added set backupcopy=yes to my .vimrc and it started working.
The solution for other editors is documented there as well.
It is a Parcel issue! I dropped it (until they fix it)
IMHO: I do not have to change my editor's behavior just to make bundler work correctly. (webpack works fine in the situation)

Reprocessing - VSCode Reason Refmt breaks project

I'm hunting a fun little bug in a tiny reprocessing test: reprocessing01.
The project builds just fine until I make a change and trigger refmt via vscode, and then the project will no longer compile.
Here's the code that compiles and runs just fine for me before making any changes.
open Reprocessing;
type stateT = {
image: imageT,
};
let setup = (env) => {
Env.size(~width=800, ~height=600, env);
let image = Draw.loadImage(
~filename="assets/Wave_pattern_by_inkelv1122_on_flickr_800w.jpg",
~isPixel=false, env);
{
image: image
}
};
let draw = ({image} as state, env) => {
Draw.background(Constants.white, env);
Draw.image(
image,
~pos=(0,0),
~width=Env.width(env),
~height=Env.height(env),
env
);
state
};
run(~setup, ~draw, ());
If I open the project in vscode, make a change such as adding let myvar = 42; at the top, and save to trigger refmt, that introduces this error:
/Users/myer/dev/react/reasonml-playground/reprocessing01/node_modules/bs-platform/lib/bsc.exe -pp "/Users/myer/dev/react/reasonml-playground/reprocessing01/node_modules/bs-platform/lib/refmt3.exe --print binary" -bs-super-errors -w -30-40+6+7+27+32..39+44+45+101 -bs-D BSB_BACKEND="bytecode" -nostdlib -I '/Users/myer/dev/react/reasonml-playground/reprocessing01/node_modules/bs-platform/lib/ocaml' -no-alias-deps -color always -c -o src/index.mlast -bs-syntax-only -bs-simple-binary-ast -bs-binary-ast -impl /Users/myer/dev/react/reasonml-playground/reprocessing01/src/index.re
File "/Users/myer/dev/react/reasonml-playground/reprocessing01/src/index.re", line 12, characters 4-5:
Error: 2817: <UNKNOWN SYNTAX ERROR>
The line in question is the last one of this code block:
Draw.loadImage(
~filename="assets/Wave_pattern_by_inkelv1122_on_flickr_800w.jpg",
~isPixel=false,
env,
);
After this, the only way out is to revert the code to before the changes introduced by refmt.
I suspect that my version of refmt is out of sync with the one required by bsb-native#2.1.1, but I'm not sure which one to install. I have:
$ refmt --version
Reason 3.0.0 # bee43b0
Is there a table that shows compatible versions between reason-cli and bs-platform?
Are there other ways I should investigate this issue or other potential root causes of this behavior?
UPDATE:
I was able to upgrade bsb-native to the master branch and it worked when building to native until I added some more code in reprocessing02
this issue is because bsb-native#2.1.1 comes with an old version of refmt (pre version 3) which can't read the code that your global refmt outputs (most likely because of the trailing commas). I'm working on making a new release 3.2.0 on all platforms, which comes with the latest refmt. If you're on OSX you can try it by just changing your dep to bsansouci/bsb-native#3.2.0, nuking node_modules and reinstalling.
Sorry for the inconvenience. I'm planning on making my release cycle tighly coupled with bsb's release cycle.

How to get Resharpers InspectCode to recognize Plugins?

I am trying to run ReSharpers command line tool InspectCode.exe. It's running fine doing it's job with the expected output.
However after my earlier attempt to get plugins to work, this time with the new version it is supposed to be supported. There is a switch in the command line interface that allows to specify the extension you want to use.
/extensions (/x) – allows using ReSharper extensions that affect code analysis. To use an extension, specify its ID, which you can find by opening the extension package page in the ReSharper Gallery, and then the Package Statistics page. Multiple values are separated with the semicolon.
But I cannot get it to work properly. I cannot even provoke any reaction to the /x switch at all. No matter how or what I pass, I get no feedback from the executable and the output is identical. I don't even get an error message when passing obvious garbage.
I tried the following commandlines for the exact same result:
inspectcode.exe /o="rcli.xml" /swea /x="ReSharper.StyleCop" "my.sln"
inspectcode.exe /o="rcli.xml" /swea /x=ReSharper.StyleCop "my.sln"
inspectcode.exe /o="rcli.xml" /swea "my.sln"
inspectcode.exe /o="rcli.xml" /swea /x=ABCDEFG "my.sln"
Result
JetBrains Inspect Code 9.1.1
Running in 64-bit mode, .NET runtime 4.0.30319.18444 under Microsoft Windows NT
6.1.7601 Service Pack 1
Enabled solution-wide analysis according to Inspect Code command line Setting.
Analyzing files
[files]
Inspection report was written to rcli.xml
What am I doing wrong? How to get extensions to work?
I already tried the R# forums, but it took them more then 24h to approve my post and so far I'm not sure someone else even read it.
Unfortunately, the support for extensions was dropped in 9.0 due to the refactorings in the "ReSharper platform". I hope that JetBrains will bring it back soon.
See RSRP-436208.
This is a late answer that might help future readers (like myself). Currently inspectcode.exe will automatically look for and use any NuGet packages that are in the same folder as the executable (source).
Example for CleanCode extension:
if you have a R# instance on some machine and install the extension, it will be placed in C:\Users\{user}\AppData\Local\JetBrains\plugins\MO.CleanCode.5.6.15
copy MO.CleanCode.5.6.15.nupkg and paste it next to inspectcode.exe
when running inspectcode with verbosity = VERBOSE, the extension should appear in the Zones list:
$cmd = "..\JetBrains.ReSharper.CommandLineTools.2019.3.4\inspectcode.exe"
$outputFile = "..\Output\$($outputName).xml"
& $cmd -o="$outputFile" $sln --verbosity=VERBOSE
Zones: (52pcs)[CodeInspectionPageImplZone, DaemonEngineZone,
DaemonZone, IAmd64CpuArchitectureHostZone, IAspMvcZone,
IBatchToolEnvironmentZone, IClrImplementationHost Zone,
IClrPsiLanguageZone, ICodeEditingOptionsPageImplZone,
IConsoleEnvironmentZone, ICppProductZone, ICpuArchitectureHostZone,
IDocumentModelZone, IEnvironmentZone, IHostSolutionZone,
IInspectCodeConsoleEnvironmentZone, IInspectCodeEnvironmentZone,
IInspectCodeZone, ILanguageAspZone, ILanguageBuildScriptsZone,
ILanguageCppZone, I LanguageCSharpZone, ILanguageCssZone,
ILanguageHtmlZone, ILanguageIlZone, ILanguageJavaScriptZone,
ILanguageMsBuildZone, ILanguageNAntZone, ILanguageProtobufZone, ILa
nguageRazorZone, ILanguageRegExpZone, ILanguageResxZone,
ILanguageVBZone, ILanguageXamlZone, INetFrameworkHostZone, INuGetZone,
IOperatingSystemHostZone, IProjectMode lZone,
IPsiAssemblyFileLoaderImplZone, IPsiLanguageZone,
IPublicVisibilityZone, IRdFrameworkZone, IRiderModelZone,
ISinceClr2HostZone, ISinceClr4HostZone, ITextContro lsZone,
IToolsOptionsPageImplZone, IWebPsiLanguageZone, IWindowsNtHostZone,
PsiFeaturesImplZone, ReplaceableByIntelliJPlatformZone, SweaZone]
Packages: (23pcs)[JetBrains.ExternalAnnotations,
JetBrains.Platform.Core.Ide, JetBrains.Platform.Core.IisExpress,
JetBrains.Platform.Core.MsBuild, JetBrains.Platform. Core.Shell,
JetBrains.Platform.Core.Text, JetBrains.Platform.Interop.CommandLine,
JetBrains.Platform.Interop.dotMemoryUnit.Framework,
JetBrains.Platform.Interop.dotMe moryUnit.Interop.Console,
JetBrains.Platform.Interop.dotMemoryUnit.Interop.Ide,
JetBrains.Platform.RdProtocol, JetBrains.Psi.Features.Core,
JetBrains.Psi.Features.Cpp .Src.Core, JetBrains.Psi.Features.src,
JetBrains.Psi.Features.Tasks, JetBrains.Psi.Features.UnitTesting,
JetBrains.Psi.Features.Web.Core, JetBrains.ReSharperAutomatio
nTools.src.CleanupCode,
JetBrains.ReSharperAutomationTools.src.CommandLineCore,
JetBrains.ReSharperAutomationTools.src.CommandLineProducts,
JetBrains.ReSharperAutomat ionTools.src.DuplicatesFinder,
JetBrains.ReSharperAutomationTools.src.InspectCode, MO.CleanCode]

Running JUnit-Tests that uses SWT-Display fails on Jenkins

I a have a few JUnit-Tests that makes use of the current Display to instantiate a few controls (TreeViewer for instance). Locally that works fine, no problem. When I commit these tests and jenkins runs the test I get a failed test for each test that makes use of Display.
My unit test uses the display variable in this manner:
#Test
public void testUtils() {
Display display = Display.getCurrent();
Shell shell = new Shell(display, SWT.NONE);
// org.eclipse.swt.widgets.Composite composite = new
// org.eclipse.swt.widgets.Composite(
// shell, SWT.NONE);
TreeViewer viewer = new TreeViewer(shell, SWT.MULTI | SWT.H_SCROLL
| SWT.V_SCROLL);
The error log jenkins generates is:
Time elapsed: 0.13 sec <<< ERROR!
org.eclipse.swt.SWTError: No more handles [gtk_init_check() failed]
at org.eclipse.swt.SWT.error(SWT.java:4109)
at org.eclipse.swt.widgets.Display.createDisplay(Display.java:902)
at org.eclipse.swt.widgets.Display.create(Display.java:890)
at org.eclipse.swt.graphics.Device.<init>(Device.java:154)
at org.eclipse.swt.widgets.Display.<init>(Display.java:499)
at org.eclipse.swt.widgets.Display.<init>(Display.java:490)
at org.eclipse.swt.widgets.Display.getDefault(Display.java:1693)
at org.eclipse.swt.widgets.Shell.<init>(Shell.java:260)
at org.eclipse.swt.widgets.Shell.<init>(Shell.java:253)
at
Is there any thing wrong with the way I am using Display in my tests? It works when executed on my local machine
The way you use Display looks OK to me. The error is likely related to the fact that your server is not running Gnome, hence SWT can't create a Display when you ask it to.
UPDATE
I just found a recent blog post, which explains what you need to do to run SWT UI tests on a headless server in more detail. Although the steps provided are meant for Hudson, they should be applicable to Jenkins as well.
It should all boil down to these two steps:
Check Run Xvnc during build (and don’t bother to check take screenshot, it doesn’t work)
Add an Execute shell build action before launching your tests with metacity –replace –sm-disable &
See the linked blog post for screenshots and more details.
You can try following two things,
execute command "xhost" or "xhost+" from your terminnal.
execute command "xhost" or "xhost+" from, jenkins terminal.