[BUG] mlir types confuse overload resolution

[helehex]

Bug description

When a function has an overload with a mlir type, and another with a trait composition (maybe exclusive to CollectionElement?), Mojo cannot resolve the one with the mlir type.

Steps to reproduce

fn test(none: None):
    pass


fn test[T: StringableCollectionElement](x: T):
    pass


# cannot bind MLIR type 'None' to trait 'StringableCollectionElement'
fn main():
    test(None)

System information

Host Information
  ================

  Target Triple: x86_64-unknown-linux
  CPU: skylake
  CPU Features: adx, aes, avx, avx2, bmi, bmi2, clflushopt, cmov, crc32, cx16, cx8, f16c, fma, fsgsbase, fxsr, invpcid, lzcnt, mmx, movbe, pclmul, popcnt, prfchw, rdrnd, rdseed, sahf, sgx, sse, sse2, sse3, sse4.1, sse4.2, ssse3, x87, xsave, xsavec, xsaveopt, xsaves

mojo 2024.8.1705 (3a3097f5)

modular 0.8.0 (39a426b5)

[helehex]

It also happens with __mlir_type.`i1` and a corresponding __mlir_attr.`0:i1` .

[msaelices]

This issue is affecting this PR: #3521

I've workaround it here: msaelices@f836400

Thanks, @helehex, for pointing me to this issue and the workaround needed.