Skip to content

BLOCKER: LPython can't find dict key, but CPython can find it #2011

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
rebcabin opened this issue Jun 23, 2023 · 5 comments · Fixed by #2014
Closed

BLOCKER: LPython can't find dict key, but CPython can find it #2011

rebcabin opened this issue Jun 23, 2023 · 5 comments · Fixed by #2014
Assignees
Labels
BLOCKER workaround not found yet bug Something isn't working

Comments

@rebcabin
Copy link
Contributor

repro: https://github.com/rebcabin/lpython/tree/brian-lasr/lasr/LP-pycharm/Issue2011

offending code:

I4C: dict[str, i32] = {
    '0': 0, '1': 1, '2': 2, '3': 3,
    '4': 4, '5': 5, '6': 6, '7': 7,
    '8': 8, '9': 9,
    'a': 10, 'b': 11, 'c': 12, 'd': 13,
    'A': 10, 'B': 11, 'C': 12, 'D': 13,
    'e': 14, 'f': 15,
    'E': 14, 'F': 15}


def cnvi(s : str, base : i32=10) -> i32:
    """Assume input has been through 'match_integer'."""
    assert base == 10 or base == 8 or base == 16 or base == 2
    result : i32 = 0
    c : str
    t : str = strip_numerical_noise(s)
    pow: i32 = base ** (len(t) - 1)
    for c in t:
        incr : i32 = pow * I4C[c]
        result += incr
        pow = (pow // base)
    return result


if __name__ == '__main__':
    assert cnvi('0b0', base=2) == 0
    assert cnvi('0b1', base=2) == 1
    assert cnvi('0b10', base=2) == 2
    assert cnvi('0b11', base=2) == 3
    assert cnvi('0b1111_0100_111', base=2) == 1959
    assert cnvi('0b7a7', base=16) == 1959  ############# ATTENTION ##############

runs:

(lp) ┌─(~/CLionProjects/lpython/lasr/LP-pycharm/Issue2011)───────────────────────────────────────────────────────────────────────────────────────────────(brian@Golf37:s012)─┐
└─(17:51:22 on brian-lasr ✹ ✭)──> PYTHONPATH='../../../src/runtime/lpython' python lasr_lexer.py                                                          ──(Thu,Jun22)─┘
(lp) ┌─(~/CLionProjects/lpython/lasr/LP-pycharm/Issue2011)───────────────────────────────────────────────────────────────────────────────────────────────(brian@Golf37:s012)─┐
└─(17:51:30 on brian-lasr ✹ ✭)──> ~/CLionProjects/lpython/src/bin/lpython -I. lasr_lexer.py                                                               ──(Thu,Jun22)─┘
KeyError: The dict does not contain the specified key
@rebcabin rebcabin added the BLOCKER workaround not found yet label Jun 23, 2023
@certik
Copy link
Contributor

certik commented Jun 23, 2023

Here is a minimal reproducible example:

from lpython import i32

def main():
    d: dict[str, i32] = {
        '2': 2, '3': 3,                
        '4': 4, '5': 5, '6': 6, '7': 7,
        '8': 8, '9': 9,
        'a': 10, 'b': 11, 'c': 12, 'd': 13,
        'A': 10, 'B': 11, 'C': 12, 'D': 13,
        'e': 14, 'f': 15,
        'E': 14, 'F': 15}
    print(d['a'])

main()

Gives:

$ PYTHONPATH=src/runtime/lpython python a.py          
10
$ lpython a.py                              
KeyError: The dict does not contain the specified key
$ lpython --backend=c a.py   
10

If I remove any more keys from the dictionary, then it passes. It only happens in the LLVM backend, C works.

@certik certik added the bug Something isn't working label Jun 23, 2023
@certik
Copy link
Contributor

certik commented Jun 23, 2023

@czgdp1807 do you think you could please have a look at this? This looks like a bug in our dictionary implementation.

@rebcabin
Copy link
Contributor Author

thanks for jumping on this :) you guys are great!

@rebcabin
Copy link
Contributor Author

verified ! :)

@certik
Copy link
Contributor

certik commented Jun 23, 2023

Keep reporting bugs!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
BLOCKER workaround not found yet bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants