Accept directory as manifest-path (default file name) or accept file not named Cargo.toml

[andrewdavidmackenzie]

Current behaviour

I think there is some behaviour of Cargo and the --manifest-path option that I think is a little inconsistent.

When no manifest path is used (e.g. cargo build) it choses Cargo.toml.
i.e. it has the notion of Cargo.toml as the default cargo manifest file, when in the CWD.
i.e. same is true when workspace refer to sub-crates, it selects 'Cargo.toml' in the named sub-folder

When you specify a manifest path to a directory...

cargo build --manifest-path=flowstdlib
error: the manifest-path must be a path to a Cargo.toml file

...then Cargo does not try to use the default file name (Cargo.toml) in the specified directory, it forces you to specify the full path including the file name.

I think that could make sense if there could be some confusion as to what file to use in said directory, but in fact you cannot specify a file that is not called Cargo.toml:

cargo build --manifest-path=flowstdlib/control/compare/flow.toml
error: the manifest-path must be a path to a Cargo.toml file

I propose:

1. You can specify a manifest path to a directory and then cargo will try to use the file Cargo.toml in that directory if it is present.

2. Allow manifest-path to specify a file that is NOT called Cargo.toml.
   I happen to have a project that needs this (long story), but overall I am unaware of issues with the use of other filenames (when specified explicitly as part of --manifest-path option. Trying other default filename would be problematic and a bad idea). Please let me know of any in comments.

Acceptance criteria

All current forms would continue to work
cargo build
cargo build --manifest-path=subdir/Cargo.toml

And other forms that currently give an error would start to work:
cargo build --manifest-path my_manifest.toml
cargo build --manifest-path ./my_manifest.toml
cargo build --manifest-path . (not very useful, but a valid directory)
cargo build --manifest-path subdir
cargo build --manifest-path subdir/
cargo build --manifest-path subdir/my_manifest.toml

If the proposal seems acceptable, I would be willing to take a stab at implementing it (having never looked at cargo code and being full of innocence and optimism... :-) )

[4TT1L4]

About the second point, this is still explicitly enforced.

The manifest_path must be ending with Cargo.toml. See main.rs#L134-L138 for the explicit check:

if let Some(specified_manifest_path) = opts.manifest_path {
    if !specified_manifest_path.ends_with("Cargo.toml") {
        print_usage_to_stderr("the manifest-path must be a path to a Cargo.toml file");
        return FAILURE;
    }

Is there a good reason to explicitly enforce this filename? I do also happen to have a project that could benefit from a secondary manifest file with a different name (long story)...

[epage]

#6690 is the issue for explicit enforcement of Cargo.toml

[epage]

I think that could make sense if there could be some confusion as to what file to use in said directory, but in fact you cannot specify a file that is not called Cargo.toml:

With #12207, you can have single-file packages in the same directory as a Cargo.toml.