Bug: Empty Closure for External Functions

[ssyram]

Phenomenon

The following code:

fn main() { [1].iter().any(|&x| x > 0); }

Yields the error:

Cannot re-check test.main as valid Low* and will not extract it.  If test.main is not meant to be extracted, consider marking it as Ghost, noextract, or using a bundle. If it is meant to be extracted, use -dast for further debugging.

Warning 4: in the arguments to core.slice.iter.{core::iter::traits::iterator::Iterator<&'a␣(T)>␣for␣core::slice::iter::Iter<'a,␣T>[TraitClause@0]}.any < int32_t > < () > [[test.main.call_mut_6e]] [[test.main.call_once_5a]], after the definition of lvalue, in top-level declaration test.main, in file test: Malformed input:
subtype mismatch:
   int32_t* -> bool (a.k.a.  int32_t* -> bool) vs:
  () ->  int32_t* -> bool (a.k.a. () ->  int32_t* -> bool)

Root of Cause

I've identified that this is caused by the following chain of passes:

1. There is a pass where empty structs (here, the empty closure struct) are removed and treated as unit type ();
2. There is a pass where the unit-type fields & arguments are removed;
3. However, in the type checking, the function any requires the associated method call_once as its argument, the function itself is with type call_once: T -> Args -> Ret, but the actual argument {...}::call_once, originally with type () -> &i32 -> bool is now simply &i32 -> bool, making the type mismatching.

Potential Solutions

First of all, this shall disappear totally after #275 , so each of the following solution is not meant to be permanent and should appear in the main branch, I'm just looking for a quick fix in my branch for current purpose.

1. empty structs are not removed, but should all be treated as void * in code-gen phase.
2. a special type-checker allowing functions to be with additional () parameters.
3. Do not remove () and simply treat all of them as void *.

Which way is a faster way?

[ssyram]

There is an even faster way: from replacing the empty structs as () to simply () *.

I think this issue is better left unresolved? As the problem still exists in the main branch, and is another strong evidence as to why we should do mono migration.