[vim/vim] behavior change in has_key() (#8546)

[Shane-XB-Qian]

Describe the bug

vim9script

def Foo(n: number): void
  var bar = {'9': 'a', 'x': 'y'}
  echomsg bar->has_key(n)
enddef

Foo('9')

Expected behavior
looks n was treated as 'string' (when has_key) in the past implicitly, but recently change made it raise e1013 err.

Environment (please complete the following information):
v8.2.3140

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

[Shane-XB-Qian]

doc:

A key is always a String.  You can use a Number, it will be converted to a
String automatically.  Thus the String '4' and the number 4 will find the same
entry.

[Shane-XB-Qian]

btw:
we had such has_key() underscore naming, but mostly we should keep sth like haskey(), looks that's the right vim style... :-)

[Bram Moolenaar]

Foo() needs to be called with a number argument. That didn't change recently, so perhaps it's a mistake in your example.

The argument of has_key() was just changed in patch 8.2.3142, thus I think this problem was already fixed.

[Bram Moolenaar]

Closed #8546.

[Shane-XB-Qian]

ok, yes, 8.2.3142 fixed it about 1 hour ago. thx.

[Bram Moolenaar]

Hah, we are used to telling users reporting a problem that their version is half a year old and suggest trying a more recent one.
Now it's down to half an hour :-).

[Shane-XB-Qian]

um, i think the problem is not about 'age' or 'old', but the test case did not cover the cases, or sometimes we knew some changes obviously would break user cases.. or some changes changed the behavior too heavy (impacted lot), otherwise we would not release the change because the ci should had stopped the process already. :-)

[Shane-XB-Qian]

actually in the real life/work we faced the same issue -- so called 'agile', specially e.g only req 1 deployment into 1 data center,
actually i missed the 'version', not sure if someone had better solution/suggestion.

[Shane-XB-Qian]

btw: e1013 check type looks very strict, or something perhaps wrong,

vim9script

call sign_define([
	\ {'name': 'sign1',
	\  'text': '=>'},
	\ {'name': 'sign2',
	\  'text': '!!'}
	\ ])

def Bar(): void
	sign_define([{'name': 'sign1',
		\  'text': '=>'},
		\ {'name': 'sign2',
		\  'text': '!!'}
		\ ])
enddef

Bar()

if you like i can open a separate ticket, or here this type checking problem was not just about some specific funcs (e.g has_key(), sign_define()) ?

[Yegappan Lakshmanan]

Hi,

On Sun, Jul 11, 2021 at 8:08 AM Shane-XB-Qian <vim-dev...@256bit.org> wrote:

btw: e1013 check type looks very strict, or something perhaps wrong,

vim9script

call sign_define([
	\ {'name': 'sign1',
	\  'text': '=>'},
	\ {'name': 'sign2',
	\  'text': '!!'}
	\ ])

def Bar(): void
	sign_define([{'name': 'sign1',
		\  'text': '=>'},
		\ {'name': 'sign2',
		\  'text': '!!'}
		\ ])
enddef

Bar()

if you like i can open a separate ticket, or here this type checking problem was not just about some specific funcs (e.g has_key(), sign_define()) ?

I have created the PR 8545 to address this issue.

Regards,

Yegappan

[vim-dev ML]

Hi,

On Sun, Jul 11, 2021 at 8:08 AM Shane-XB-Qian ***@***.***>

wrote:

> btw: e1013 check type looks very strict, or something perhaps wrong,
>
> vim9script
> call sign_define([
> \ {'name': 'sign1',
> \ 'text': '=>'},
> \ {'name': 'sign2',
> \ 'text': '!!'}
> \ ])
> def Bar(): void
> sign_define([{'name': 'sign1',
> \ 'text': '=>'},
> \ {'name': 'sign2',
> \ 'text': '!!'}
> \ ])enddef
> Bar()
>
> if you like i can open a separate ticket, or here this type checking
> problem was not just about some specific funcs (e.g has_key(),
> sign_define()) ?
>
>
> I have created the PR 8545 to address this issue.

Regards,
Yegappan

[Shane-XB-Qian]

and this one after 8545
var popupID = text->popup_atcursor({moved: 'any'})
expected string but got any

—
You are receiving this because you commented.

[Yegappan Lakshmanan]

Hi,

On Sun, Jul 11, 2021 at 11:40 AM Shane-XB-Qian <vim-dev...@256bit.org> wrote:

and this one after 8545
var popupID = text->popup_atcursor({moved: 'any'})
expected string but got any

Thanks for reporting the issue. I have created PR #8551 to address

this issue. Let us know if you see Vim9 type check issues with any

other function.

Regards,

Yegappan

[vim-dev ML]

Hi,

On Sun, Jul 11, 2021 at 11:40 AM Shane-XB-Qian ***@***.***>

wrote:

> and this one after 8545
> var popupID = text->popup_atcursor({moved: 'any'})
> expected string but got any
>
>
>
Thanks for reporting the issue. I have created PR #8551 to address
this issue. Let us know if you see Vim9 type check issues with any
other function.

Regards,
Yegappan

[Shane-XB-Qian]

@brammool @yegappan
bnr->setbufvar('&buflisted', true)
// "expected string but got bool"

doc:

In Vim9 script one can use "true" for v:true, "false" for v:false and "null"
for v:null. 

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub, or unsubscribe.

Triage notifications on the go with GitHub Mobile for iOS or Android.

[Yegappan Lakshmanan]

Hi,

On Thu, Aug 26, 2021 at 7:22 PM Shane-XB-Qian <vim-dev...@256bit.org> wrote:

@brammool @yegappan
bnr->setbufvar('&buflisted', true)
// "expected string but got bool"

The new variable value is the base argument for the setbufvar()

method call and the buffer number is not the base argument.

From the help for setbufvar:

    Can also be used as a method, the base is passed as the
    third argument:
        GetValue()->setbufvar(buf, varname)

So you need to use

     true->setbufvar(bnr, '&buflisted')

- Yegappan

[vim-dev ML]

Hi,

On Thu, Aug 26, 2021 at 7:22 PM Shane-XB-Qian ***@***.***>
wrote:

> @brammool <https://github.com/brammool> @yegappan
> <https://github.com/yegappan>

> bnr->setbufvar('&buflisted', true)
> // "expected string but got bool"
>

The new variable value is the base argument for the setbufvar()
method call and the buffer number is not the base argument.

From the help for setbufvar:

Can also be used as a method, the base is passed as the
third argument:
GetValue()->setbufvar(buf, varname)

So you need to use

true->setbufvar(bnr, '&buflisted')

- Yegappan


> doc:
>
> In Vim9 script one can use "true" for v:true, "false" for v:false and "null"
> for v:null.
>
>
>

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

[Shane-XB-Qian]

the base is passed as the third argument

maybe not a good idea, since most the first argument was the base,
and actually this case is from your lsp plugin, so looks you were confused too...... :-)

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub, or unsubscribe.

[Yegappan Lakshmanan]

Hi,

On Thu, Aug 26, 2021 at 9:49 PM Shane-XB-Qian <vim-dev...@256bit.org> wrote:

the base is passed as the third argument

maybe not a good idea, since most the first argument was the base,
and actually this case is from your lsp plugin, so looks you were confused too...... :-)

I have pushed a fix for the LSP plugin.  It is good that the new Vim9 argument

type check caught this issue.

Regards,

Yegappan

[vim-dev ML]

Hi,

On Thu, Aug 26, 2021 at 9:49 PM Shane-XB-Qian ***@***.***>

wrote:

> the base is passed as the third argument
>
> maybe not a good idea, since most the first argument was the base,
> and actually this case is from your lsp plugin, so looks you were confused
> too...... :-)
>
>
>
I have pushed a fix for the LSP plugin. It is good that the new Vim9
argument
type check caught this issue.

Regards,
Yegappan

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

[Shane-XB-Qian]

ok, but unfortunately, it's raising error when it's really called.
so 'used as a method' this is a case to prove this would code be confused.

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub, or unsubscribe.