Allow searching multiple Cargo targets or the entire workspace

[kpreid]

Right now, cargo asm errors out if not enough package and target selection options are passed to choose a single Cargo target. However, in the presence of generics or inlining, it may not be possible to know up front what target contains the function of interest. This results in my having to run multiple cargo asm commands to guess where the monomorphized function, if any, landed.

I would like cargo asm to automate this by allowing searching multiple targets if multiple targets are present. The output should specify the target in addition to the symbol name.

This may be slow, so it could print advice suggesting the appropriate filtering options for future runs. It could also cache symbols found in previous runs and build only that target next time, but that could guess wrong and hide ambiguity, particularly if a code change changes inlining decisions.

[pacak]

This is an interesting idea. Not sure if I ever had a problem like that...

I don't think we want to do the slow thing by default - in my main use case this would mean sequentially compiling a few dozen executables taking an hour or more, but making it optional and allowing to pass multiple targets or the whole workspace (cargo asm --workspace) would be fine by me.

I see a few gotchas with that though:

• cargo rustc doesn't allow passing multiple targets so this will be sequential - taking more time than a regular cargo build would.
• rustc might produce different results compared to cargo build invocation due to feature unification. It might not produce the same results anyway because of me having to force a single codegen unit, but at least the code would be producing the same result, with different features this can be anything.

So in the ideal world we just pass whatever we want to cargo rustc, it deals with unification, concurrently compiles what's needed and it gives back a list of produced .s files, in practice...

Anyway, I'll see what it takes to implement it. Might take a bit.

[kpreid]

A narrower selection procedure that still serves my needs would be “this [binary/test/bench] target and all of its dependencies in the workspace”. That would narrow down the number of targets, and it would still be able to find a function anywhere that the given binary depends on.