Weird bug in rust playground not present in local rust installation

help
1 
#![forbid(
    clippy::all,
    clippy::correctness,
    clippy::suspicious,
    clippy::style,
    clippy::complexity,
    clippy::perf,
    clippy::pedantic,
    clippy::nursery,
)]

use std::   fmt::Debug     as Á;
use std:: slice::IterMut   as À;
use std::   mem::transmute as Â; type

à <'malformed, A>=
À <'malformed, A>; type

Ä =              (    [((),); 0],   ((), ()));                 pub trait  
Ą <Ā>            {    fn a          (&mut self) -> Ã<'_, Ā>; } fn á<
Å :Á>(à: Å)      {    println!      ("{à:?}");               }
/*hence, */           macro_rules   /* the land of rust*/    !
A                {                  ($å:tt)     =>           { [$å; 1024] };     }     impl 
Ą<()> for A!(()) {    fn a          (&mut self) -> Ã<'_, ()> { self.iter_mut() } } impl 
Ą<Ä>  for A!(Ä)  {    fn a          (&mut self) -> Ã<'_, Ä > { self.iter_mut() } } fn main

() { let mut a = [(); 1024];
     for a in a.a() { *a = unsafe { Â::<((),), ()>(((),)) };}
     A!(([((),); 0], ((), ()))).a().for_each(á);
}

(Playground)

In this specific snippet, the rust playground clippy states that "i don't have a main function" and a function named main is "never used".

2

It doesn't when I try your playground. Clippy doesn't complain at all.

3

The only issue is having the main function in the same line as the impl. You can reproduce the warning with just that (Playground)

2 Likes
4

It (Clippy) doesn't.

The payground itself uses a simple heuristic for checking whether you wrote code for a runnable binary or a library, because it doesn't allow specifying the crate type in any other way. If and only if you have an fn main() at the start of a line, will it assume you want a runnable binary.

Weird bug

This is not a bug, and much less "weird". The code formatting in the snippet you posted is – needless to say – highly non-idiomatic. Why would you expect tools to work well with it?

5

I would expect rustfmt (as the tool that drives cargo fmt) to cope with it. And, indeed, it does - once rustfmt has done its thing, the playground is fine with this code, too.

6

Of course, because that's the whole point of rustfmt. But OP's complaint was about clippy and the playground, neither of which are reasonable complaints:

  • clippy is specifically designed to detect bad code, which that code is; and
  • the Playground is meant to be used by humans who write human-readable and human-like code. The "what weird corner cases the parser can deal with" question is answered by the test suite in the compiler (hopefully), not by ramming it into the Playground.
1 Like
7

First of all, my code is not "bad". This bad boy passes all of the clippy checks above and only has bad formatting, and bad variable naming. Why would a working language have any issue with bad formatted but proper syntaxed code? I see no problem with this.

Second of all, I was surprised that the playground clippy worked like that, thanks for letting me know. This probably isn't a huge deal of a bug, but it would be better for the playground to choose whether a given crate is a binary of a library. Instead of relying on heuristics, we should be able to choose this. I know, it will only incur more unmaintanable code, more things to worry about in the perspective of the playground devs, but this was my foundings when I experimented with the language. It might be a corner case, but not everyone uses rust-fmt.

The thing about me calling the bug "weird" comes from the fact that it was reproducible on the playground but not on my local installation. I thought to myself, "did I install Rust wrong or something? am I using outdated software?" That's why.

8

You actually can. The heuristics define which mode to use by default, but you can explicitly choose the mode to use by clicking on the three dots next to the Build button and then choosing the Run option instead.

2 Likes
9

That already implies it's bad code. "correct" (let alone "it compiles") is not a sufficient condition for code to be good.

The language doesn't have any problems with it insofar as compiling it correctly is the concern. The thing that chokes on it is the Playground, which I repeat is:

  1. not the same as the compiler or the linter, and
  2. is designed to host human-readable code.

TL;DR: you are wrong.

3 Likes
10

This is not clippy. It's the playground's internal heuristic for "should choose the "Run" or "Build" option as the default for the big button?". The playground clippy output for your sample code is:

⣿
Standard Error

    Checking playground v0.0.1 (/playground)
warning: function `á` is never used
  --> src/lib.rs:20:67
   |
20 | Ą <Ā>            {    fn a          (&mut self) -> Ã<'_, Ā>; } fn á<
   |                                                                   ^
   |
   = note: `#[warn(dead_code)]` on by default

warning: function `main` is never used
  --> src/lib.rs:25:87
   |
25 | Ą<Ä>  for A!(Ä)  {    fn a          (&mut self) -> Ã<'_, Ä > { self.iter_mut() } } fn main
   |                                                                                       ^^^^

warning: `playground` (lib) generated 2 warnings
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.78s

You will notice no mention of "main" in here at all; and similarly, if you override the heuristic from the three dots menu, you will find no mention of "main", either.

The only reason the playground does this is that it's meant for human-written code, where you're more likely to have written fn mian() { by mistake than to have weirdly formatted code that breaks the heuristic. Thus, the playground's heuristic issues a warning that it's chosen to build and not run so that human users of the playground with reasonably cleanly formatted code (or users who've run rustfmt from the "Tools" menu) get a hint at why the playground has chosen to build their code (only) instead of building and running their code.

11

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.