Too many warnings with the new unconditional_recursion lint

[oderwat]

I think the new unconditional_recursion lint has a bug. For example I get a warning for this code:

#![allow(unstable)]
fn print_type_of<T>(_: &T) -> () {
    let type_name =
        unsafe {
            (*std::intrinsics::get_tydesc::<T>()).name
        };
    println!("{}", type_name);
}

fn main() {
    print_type_of(&main);
}

<anon>:10:1: 12:2 warning: function cannot return without recurring, #[warn(unconditional_recursion)] on by default
<anon>:10 fn main() {
<anon>:11     print_type_of(&main);
<anon>:12 }
<anon>:11:20: 11:24 note: recursive call site
<anon>:11     print_type_of(&main);
                             ^~~~
<anon>:10:1: 12:2 help: a `loop` may express intention better if this is on purpose
<anon>:10 fn main() {
<anon>:11     print_type_of(&main);
<anon>:12 }

rustc 1.0.0-nightly (458a6a2 2015-01-25 21:20:37 +0000)

[japaric]

cc @huonw

[huonw]

Wow, I considered situations like this, but I didn't think it would occur often, or at all; I think I was too optimistic. I assume your example is reduced from a larger one; out of interest, what's your use for unconditionally referring to a function inside itself?

[oderwat]

Well. Actually this code is just part of some examples I put together for testing what types stuff has. Nothing for production or with real meaning.

    print_type_of(&12);
    print_type_of(&12i64);

    print_type_of(&12.0);
    print_type_of(&12.0f32);

    print_type_of(&"Test");
    print_type_of(&"Test".as_slice());
    print_type_of(&"Test".to_string());

    print_type_of(&(1i32..2));

    print_type_of(&[1,2,3]);
    print_type_of(&vec![1,2,3,4]);

    print_type_of(&main);
    print_type_of(&print_type_of::<isize>);

    print_type_of(&|:| 1);
    print_type_of(&|&:| 1);
    print_type_of(&|&mut:| 1);

    print_type_of(&|: x: i32| x);

Are all the cases I have in that. I had the same warning with the pretty fresh parser-combinators crate which was topic in reddit a day ago. There I get a warning for this:

impl <I, O, P> Parser for Box<P>
  where I: Stream, P: Parser<Input=I, Output=O> {
  type Input = I;
  type Output = O;
  fn parse_state(&mut self, input: State<I>) -> ParseResult<O, I> {
    (*self).parse_state(input)
  }
}

https://github.com/Marwes/parser-combinators/blob/master/src/primitives.rs#L235

Which also seems not right to me. I just posted my "print_type_of(&main)" example because I thought it is pretty obviously not what we should get a warning for :)

[huonw]

Ah I see.

By the way, the latter is actually incorrect: Box<P>.parse_state is calling itself: it should be (**self).parse_state(input).

[retep998]

I recently ran into this as well when passing read_callback to ReadFileEx inside read_callback. Async callbacks like this don't run the risk of stack overflows the way traditional recursion does so the warning is just a nuisance.

[oli-obk]

I noticed this when writing a ffi that uses callbacks. If the callback calls a function and passes itself as a parameter, this warning triggers. Obviously we don't know anything about the foreign function and therefore it might be true. But it's not really unconditional recursion. PlayPen Example

pub type Callback = extern fn();

extern {
    pub fn something(arg: Callback);
}

extern fn cb() {
    unsafe{ something(cb); }
}