努力报了一个bug到上游 There is a problem with the test code of the vim-jedi 0.11.2-3 package. The package build failed under both the riscv64 and x86-64 architectures. According to the log output, the signature test file reported an error when entering the test phase.
package version(s):vim-jedi 0.11.2-3，Attached is a patch:python-3.13-accept-test-results.patch
My operating environment is an x86-64 environment virtual machine of the arch architecture of Windows WSL. The process is as follows:
Enter the folder where the jedi-vim-0.11.2 source code folder and PKGBUILD file exist, then enter the jedi-vim-0.11.2 source code folder, and execute patch -Np1 -i ../python-3.13-accept-test-results.patch
Then execute py.test
Wait for about 7 seconds and find an error
I modified the test file. Here are my ideas for modification：
This is the relevant code for the command line truncation error in the eighth test of /test/vsepr/sinagature.vim
Here is the relevant code for the show_call_signatures function called by this test
After debugging, I found that according to the original test code, the process should have entered the fourth if function to execute g:jedi#show_call_signatures = 2, but in fact it returned in the third if, and no content was output, resulting in the return of \n. The reason is that signatures = get_script().get_signatures(*get_pos()) is an empty list And the signature cannot be read. I think it is related to <BS> returning to the end of the previous line and directly inputting, and it is impossible to return the signature according to the independently input function name.
I deleted the <BS> in the code in the patch, and then performed the same operation as above, and found that the test passed
There is a problem with the test code of the vim-jedi 0.11.2-3 package. The package build failed under both the riscv64 and x86-64 architectures. According to the log output, the signature test file reported an error when entering the test phase.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
<buffer=5> call jedi#clear_call_signatures() Last set from ~/vim-jedi/jedi-vim-0.11.2/autoload/jedi.vim line 604 if exists('b:_jedi_orig_updatetime') | let &updatetime = b:_jedi_orig_updatetime | unlet b:_jedi_orig_updatetime | endif Last set from ~/vim-jedi/jedi-vim-0.11.2/autoload/jedi.vim line 608 ok 2 - signatures multiple buffers 2 buffers wiped out ok 3 - signatures simple after CursorHoldI with only parenthesis ok 4 - signatures highlights correct argument ok 5 - signatures no signature ok 6 - signatures signatures disabled staticmethod(f: Callable[..., Any]) foo(a, b) ok 7 - signatures command line simple not ok 8 - signatures command line truncation Expected Signature() == "\n".funcname."(arg1, …)" at line 15 Actual value: "\n" Expected value: "\naaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa(arg1, …)" ok 9 - signatures command line no signature
exe 'normal sa, b, ' Expect Signature() == "\n".funcname."(…, c)"
g/^/d put = 'def '.funcname.'('.repeat('b', 20).', arg2):' put = ' pass' execute "normal o\<BS>".funcname."( " Expect Signature() == "\n".funcname."(…)" end
Here is the relevant code for the show_call_signatures function called by this test
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
def show_call_signatures(signatures=()): if int(vim_eval("has('conceal') && g:jedi#show_call_signatures")) == 0: return
#We need to clear the signatures before we calculate them again. The #reason for this is that call signatures are unfortunately written to the #buffer. clear_call_signatures() if signatures == (): signatures = get_script().get_signatures(*get_pos())
if not signatures: return
if int(vim_eval("g:jedi#show_call_signatures")) == 2: return cmdline_call_signatures(signatures) …
After debugging, I found that according to the original test code, the process should have entered the fourth if function to execute g:jedi#show_call_signatures = 2, but in fact it returned in the third if, and no content was output, resulting in the return of \n. The reason is that signatures = get_script().get_signatures(*get_pos()) is an empty list And the signature cannot be read. I think it is related to <BS> returning to the end of the previous line and directly inputting, and it is impossible to return the signature according to the independently input function name.
I deleted the <BS> in the code in the patch, and then performed the same operation as above,
exe 'normal sa, b, ' Expect Signature() == "\n".funcname."(…, c)"
g/^/d put = 'def '.funcname.'('.repeat('b', 20).', arg2):' put = ' pass' execute "normal o".funcname."( " Expect Signature() == "\n".funcname."(…)"
and found that the test passed
Do you think this is a good career change? If you think it is, I will open a PR.
sbcl riscv64 callback unspported
Description:
There is a failure when attempting to load or run the cl-cffi test suite on the RISC-V 64-bit (rv64gc) architecture using SBCL 2.5.2. The process fails with an unhandled SIMPLE-ERROR: please implement.
The error originates from the internal function SB-ALIEN-INTERNALS:ALIEN-CALLBACK-ASSEMBLER-WRAPPER when trying to handle a CFFI callback, specifically during the loading of the compiled callbacks.fasl file from the cffi-tests system via ASDF.
This suggests that the necessary low-level assembly code generation for C-to-Lisp callbacks has not yet been implemented for the RISC-V 64-bit architecture in this version of SBCL. Relevant C compilation command showing target architecture:
My operating environment is an riscv64 environment virtual machine of the arch architecture of Windows WSL.
reproduce
The process is as follows:
Obtain the cl-cffi source code and installed all dependencies
Attempt to load the cffi-tests ASDF system, running the provided test script: sbcl –script tests/run-tests.lisp
Expected Result:
The cffi-tests system should load without error, or if callbacks are unsupported, perhaps fail with a more specific “Unsupported feature” error.
Actual Result:
An unhandled SIMPLE-ERROR: please implement is signaled from internal FFI callback machinery.
“please implement” error: This error message appears in ALIEN-CALLBACK-ASSEMBLER-WRAPPER and means that the SBCL developers have not yet written the assembly wrapper code required to generate callbacks for the current target platform (RISC-V 64-bit).
alipay
