Skip to content
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

set equality silently gives wrong results instead of CT error for incompatible types #18396

Open
timotheecour opened this issue Jun 30, 2021 · 1 comment
Labels
Invalid Code Acceptance Everything related to compiler not complaining about invalid code

Comments

@timotheecour
Copy link
Member

timotheecour commented Jun 30, 2021

Example 1

when true:
  # xxx this fails in c, js, vm and gives cgen error in cpp
  # it should either give CT error or succeed (special casing literal)
  template main =
    block:
      var s1: set[char] = {'a', 'b'}
      var s2: set['a'..'z'] = {'a', 'b'}
      echo s2 == {'a', 'b'}
  static: main()
  main()

nim r main

Current Output

vm:true
js:true
c:false
cpp:cgen error:

/Users/timothee/git_clone/nim/timn/build/nimcache/@mt12496.nim.cpp:152:59: error: cast from pointer to smaller type 'tySet_tyChar__PvbCylXV13Xvtg1HZuvI8A' (aka 'unsigned int') loses information
                T2_[0] = nimBoolToStr((s2X60gensym1__t4950525754_17 == ((tySet_tyChar__PvbCylXV13Xvtg1HZuvI8A) (TM__PT0bVxrv4y8D21sJjCuaUw_2))));

Expected Output

option 1: CT error (simpler)
option 2: special case literals and return true in this case (using implicit conversion to LHS)

Example 2

this works fine:

when defined case2:
  template main =
    block:
      var s1: set[char] = {'a', 'b'}
      var s2: set['a'..'z'] = {'a', 'c'}
      doAssert not compiles(s1 + s2)
      doAssert not compiles(s2 + s1)
      doAssert not compiles(s1 == s2)
      doAssert not compiles(s2 == s1)
      doAssert s1 + s1 == s1
      doAssert s2 + s2 == s2
      doAssert s1 + s1 == {'a', 'b'}
  static: main()
  main()

Additional Information

@timotheecour timotheecour added the Invalid Code Acceptance Everything related to compiler not complaining about invalid code label Jun 30, 2021
@metagn
Copy link
Collaborator

metagn commented Jan 16, 2022

I'm guessing the issue here is that the literal type is pretending to be inferred as set['a'..'z'] but is becoming set[char] somehow. So it's #16270 for literals.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Invalid Code Acceptance Everything related to compiler not complaining about invalid code
Projects
None yet
Development

No branches or pull requests

2 participants