Check clippy::large_stack_frames (blocked on next release)

[bjoernQ]

Enables https://rust-lang.github.io/rust-clippy/master/index.html#large_stack_frames with a threshold of 1024

While the lint is not very accurate it might give users an indication and it's easy enough to disable it

[bugadani]

That's a weird number 😅

[bjoernQ]

yeah - maybe 3072 would be still better than nothing?

[bugadani]

I'd be less surprised with 2048, I don't mind the actual value just 2048 + 48 is a weird one

[bugadani]

What if we allow the lint on the main function, instead of guessing a value that will break anyway?

[bjoernQ]

the vanilla freshly generated project fails with "this function may allocate 2056 bytes on the stack"

I was considering to allow it instead for ble-trouble - but even 3096 would still keep people from allocating 74k stack frames 🤔

[bugadani]

Sure thing, but memory in main() isn't that different from static variables, except that the linker doesn't know about it. My thinking is: people can and will happily allocate buffers in main, why not? But if we have a random number in place and their solution is to disable the check globally, then we didn't end up helping. On the other hand, if we allow main to be whatever it wants to be, the user will be less inclined to just disable the check.

[bugadani]

Although I guess this depends on how often people overflow the stack on the main core in fn main

[bjoernQ]

true - especially to avoid static mut

I guess we can allow it with a reason explaining they should still be careful ..... only problem right now: it seems the #[esp_rtos::main] macro doesn't preserve the attributes 🤔

then we should probably fix that first and let this sit for a while until the next HAL release

[bugadani]

Sounds good

[bjoernQ]

not ideal but Trouble needs more