test_completion[lambdas:112]: returns list() instead of int()

[bnavigator]

Hi,

I get this new test failure on the openSUSE build when trying to update from 0.18.0 to 0.18.1:

[   72s] _________________________ test_completion[lambdas:112] _________________________
[   72s] 
[   72s] case = <IntegrationTestCase: /home/abuild/rpmbuild/BUILD/jedi-0.18.1/test/completion/lambdas.py:112 '[a for a in [1,2] if lambda: 3][0]'>
[   72s] monkeypatch = <_pytest.monkeypatch.MonkeyPatch object at 0x7f4961af44f0>
[   72s] environment = <SameEnvironment: 3.10.1 in /usr>, has_django = False
[   72s] 
[   72s]     def test_completion(case, monkeypatch, environment, has_django):
[   72s]         skip_reason = case.get_skip_reason(environment)
[   72s]         if skip_reason is not None:
[   72s]             pytest.skip(skip_reason)
[   72s]     
[   72s]         if (not has_django) and case.path.endswith('django.py'):
[   72s]             pytest.skip('Needs django to be installed to run this test.')
[   72s]         repo_root = helpers.root_dir
[   72s]         monkeypatch.chdir(os.path.join(repo_root, 'jedi'))
[   72s] >       case.run(assert_case_equal, environment)
[   72s] 
[   72s] /home/abuild/rpmbuild/BUILD/jedi-0.18.1/test/test_integration.py:47: 
[   72s] _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
[   72s] /home/abuild/rpmbuild/BUILD/jedi-0.18.1/test/run.py:217: in run
[   72s]     return testers[self.test_type](compare_cb, environment)
[   72s] /home/abuild/rpmbuild/BUILD/jedi-0.18.1/test/run.py:265: in run_inference
[   72s]     return compare_cb(self, is_str, should)
[   72s] _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
[   72s] 
[   72s] case = <IntegrationTestCase: /home/abuild/rpmbuild/BUILD/jedi-0.18.1/test/completion/lambdas.py:112 '[a for a in [1,2] if lambda: 3][0]'>
[   72s] actual = {'builtins.list()'}, desired = {'builtins.int()'}
[   72s] 
[   72s]     def assert_case_equal(case, actual, desired):
[   72s]         """
[   72s]         Assert ``actual == desired`` with formatted message.
[   72s]     
[   72s]         This is not needed for typical pytest use case, but as we need
[   72s]         ``--assert=plain`` (see ../pytest.ini) to workaround some issue
[   72s]         due to pytest magic, let's format the message by hand.
[   72s]         """
[   72s] >       assert actual == desired, """
[   72s]     Test %r failed.
[   72s]     actual  =
[   72s]     %s
[   72s]     desired =
[   72s]     %s
[   72s]     """ % (case, indent_block(str(actual)), indent_block(str(desired)))
[   72s] E       AssertionError: 
[   72s] E         Test <IntegrationTestCase: /home/abuild/rpmbuild/BUILD/jedi-0.18.1/test/completion/lambdas.py:112 '[a for a in [1,2] if lambda: 3][0]'> failed.
[   72s] E         actual  =
[   72s] E             {'builtins.list()'}
[   72s] E         desired =
[   72s] E             {'builtins.int()'}
[   72s] E         
[   72s] E       assert {'builtins.list()'} == {'builtins.int()'}
[   72s] E         Extra items in the left set:
[   72s] E         'builtins.list()'
[   72s] E         Extra items in the right set:
[   72s] E         'builtins.int()'
[   72s] E         Full diff:
[   72s] E         - {'builtins.int()'}
[   72s] E         ?             ^...
[   72s] E         
[   72s] E         ...Full output truncated (3 lines hidden), use '-vv' to show

It fails on Python 3.9 and 3.10 but not on 3.6 and 3.8:
jedi_py36_py39_log.txt
jedi_py38_log.txt
jedi_py310_log.txt

since it obviously doesn't fail on your CI, there might be something wrong in our setup?

[davidhalter]

Good question, this is extremely weird, since this involves a lot of code that hasn't been changed for a long long time... I'm sorry, but for now I'm pretty much unable to fix this, as long as I cannot debug it...

[PeterJCLaw]

Not sure what's changed, but CI does now seem to reproduce this (and I can reproduce it locally too).

[PeterJCLaw]

Hrm, looks like this goes away if you downgrade to parso < 0.8.3.

[PeterJCLaw]

Ah, davidhalter/parso@8dee324 seems likely to be the cause. Seems like the fix is just to mark this test as <3.9? Or maybe change the test to allow the new behaviour (the comments above the test imply it's mostly there to ensure it doesn't error rather than for behaviour).

[davidhalter]

@PeterJCLaw Thanks for debugging this and finding the cause!