Add option to override --crate-name from kani

[adpaco]

Adds a hidden --crate-name option to standalone Kani (i.e., kani) only. This option allows users to override the crate name used during the compilation of single-file Rust programs, making it easier to apply Kani to non-Cargo projects (see #3046 for more details).

Resolves#3046

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 and MIT licenses.

[adpaco]

I'm stuck with the test because the last step throws the error:

error[E0463]: can't find crate for `a` which `b` depends on
--> c/src/lib.rs:3:1
|
3 | extern crate b;
| ^^^^^^^^^^^^^^^ can't find crate
error: aborting due to 1 previous error
For more information about this error, try `rustc --explain E0463`.

The tree for the test project looks like:

test_project/
├── a/
│ ├── src/
│ │ └── lib.rs
├── b/
│ ├── src/
│ │ └── lib.rs
├── c/
│ ├── src/
│ │ └── lib.rs

In the project, c depends on b, which in turn depends on a. I'm getting the error in the last step when I attempt to run kani on c/src/lib.rs with

RUSTFLAGS="--edition 2021 --extern b=b/src/libb.rlib --extern a=a/src/liba.rlib" kani c/src/lib.rs

Unfortunately, the --extern a=a/src/liba.rlib doesn't seem to make any difference here. That said, I'm also getting the same error if I follow similar compilation steps with rustc:

rustc --crate-type=lib --crate-name=a a/src/lib.rs
rustc --crate-type=lib --extern a=liba.rlib b/src/lib.rs --crate-name=b
rustc --crate-type=lib --extern b=libb.rlib --extern a=liba.rlib c/src/lib.rs --crate-name=c

These steps also result in the error posted above. Therefore, it's not clear to me how to communicate this transitive dependency to rustc. It's not even clear to me if it should be needed since the dependency was already declared when we compiled b... Thoughts? @celinval@rodionov

[adpaco]

Just after writing that long comment, I tried adding extern crate a; to c/src/lib.rs and that works 😆

[rodionov]

Many thanks for investigating this @adpaco-aws @celinval! Glad it has been resolved :)

Some additional thoughts on it. According to https://doc.rust-lang.org/rustc/command-line-arguments.html#--extern-specify-where-an-external-library-is-located

"
...
Specifying --extern has one behavior difference from extern crate: --extern merely makes the crate a candidate for being linked; it does not actually link it unless it's actively used. In rare occasions you may wish to ensure a crate is linked even if you don't actively use it from your code: for example, if it changes the global allocator or if it contains #[no_mangle] symbols for use by other programming languages. In such cases you'll need to use extern crate.
...
"

Since crate c doesn't actually use crate a, then crate a isn't being linked to crate c even though --extern a=liba.rlib is provided. Additionally, --extern flag is used to specify direct dependencies. Thus, this possibly explains why rustc cannot find crate a which is an indirect dependency of c.

In my experiments, I used additional rustc flag -L (https://doc.rust-lang.org/rustc/command-line-arguments.html#option-l-search-path) to provide directory path where both liba.rlib and libb.rlib are located. As a result, your change worked fine for me even without including extern crate a; -- rustc was able to figure out the transitive dependency on a.

Thanks again for fixing this!