Syntax extension for static stack analysis

[bharrisau]

Stay calm - this is no more than an idea in progress.

I’m curious if anyone else is looking into stack safety through compile time analysis - a subset of Rust without recursion or calloca. Based on my initial investigation, there would need to be some small changes to the LLVM shim to enable calling addPassesToEmitFile() with a StopAfter as the prologue pass.

I could see a lint copying the AST, doing a dummy codegen pass and extracting the stack sizes from the resulting LLVM context.

Is anyone doing work in this area already?

[tbu]

I think you also need to disallow virtual function calls. As far as I know, Rust’s IO uses virtual function calls, so you woudln’t even have this…

[arcto]

Are virtual function calls not just conditional calls, i.e.

match type_id {
   A => a_foo(),
   B => b_foo(),
   _ => base_foo()
}

and thus, the maximum stack usage can be inferred?

[tbu]

Virtual function calls need a struct (usually implicit via a trait):

struct Virtual {
    func: fn (int) -> uint,
}

Then a virtual function call looks like this:

fn do_stuff(v: Virtual) -> uint {
    v.func(10)
}

v.func could be any function with that signature…

[bharrisau]

Are you talking about dynamic dispatch for Box<Virtual>? In that case we could just get the maximum stack of any impl?

[bharrisau]

Note: Don’t post after long plane trips.

Totally mis-read your post sorry. Yep, there are some things you can’t handle - but we can handle the majority of cases and stick the rest in unsafe for the time being.

But it doesn’t look like this is on many people’s radar.

[tbu]

Are you talking about dynamic dispatch for Box<Virtual>? In that case we could just get the maximum stack of any impl?

I was actually talking about this, yes. The problem is that you need to know the whole program for this analysis.

[system]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.