refactor(test): Move cargo-config into a dir
This is split out of #11912 and is prep for adding more UI tests.
Generally our UI tests are in a directory named after the full cargo command (`cargo config`). These tend to use `snapbox`.
Here we are tests for the `cargo config` command not written by `snapbox` in a `cargo_config.rs` file. This conflicts with adding snapbox UI tests later in a `cargo_config/` folder. Upon looking at this file, it appears to be UI tests, so I think it would make sense to move them into the `cargo_config/` folder. Definitely wouldn't make sense to move them into `config.rs` since that is general config testing.
This is split out of #11912 and is prep for adding more UI tests.
Generally our UI tests are in a directory named after the full cargo
command (`cargo config`). These tend to use `snapbox`.
Here we are tests for the `cargo config` command not written by
`snapbox` in a `cargo_config.rs` file. This conflicts with adding
snapbox UI tests later in a `cargo_config/` folder. Upon looking at this
file, it appears to be UI tests, so I think it would make sense to move
them into the `cargo_config/` folder. Definitely wouldn't make sense to
move them into `config.rs` since that is general config testing.
Currently, the UI tests are
- `cargo add`
- `cargo new`
- `cargo remove`
- `init`
One of these is not like the others. This change renames `init` to
`cargo_init` to suggest it is the UI tests for the `cargo init` command,
rather than `init` functionality.
feat(crates-io): expose HTTP headers and Error type
### What does this PR try to resolve?
This is part of #11521.
[RFC 3231] mentions the authentication process could have an additional **challenge-response mechanism** to prevent potential replay attacks. The challenge usually comes from HTTP `www-authenticate` header as a opaque string. When a client gets a 401/403 response with such a challenge, it may attach the `challenge` to the payload and request again to anwser the challenge.
```
➡️ cargo requests
⬅️ server responds with `www-authenticate` containing some opaque challenge string
➡️ cargo automatically requests again without any user perception
⬅️ server responds ok
```
However, `crates-io` crate doesn't expose HTTP headers. There is no access to `www-authenticate` header.
This PR make it expose HTTP headers and the custom `Error` type, so `cargo` can access and do further on the authentication process.
[RFC 3231]: https://rust-lang.github.io/rfcs/3231-cargo-asymmetric-tokens.html#the-authentication-process
`parent_remote_url` used to be `&str` before #12244. However, we changed
the type to `Url` and it started failing to parse scp-like URLs since
they are not compliant with WHATWG URL spec.
In this commit, we change it back to `&str` and construct the URL
manually. This should be safe since Cargo already checks if it is a
relative URL for that if branch.
fix(embedded): Always generate valid package names
### What does this PR try to resolve?
The sanitization logic uses a placeholder for the first character that isn't valid in the first character position. #12329 took the approach of always using `_` which has the problem of mixing separators if the user used `-` or we had other placeholders to insert. Instead, this takes the approach of stripping the leading invalid characters and using a placeholder name if nothing is left.
Fixes#12330
### How should we test and review this PR?
Per-commit. The first adds tests so the change in behavior can be observed over each additional commit.
### Additional information
I was also hoping to make the binary name not use placeholders by setting `bin.name` to `file_stem` but then I got
```
Compiling s-h-w-c- v0.0.0 (/home/epage/src/personal/cargo/target/tmp/cit/t133/foo)
error: invalid character `'.'` in crate name: `s_h.w§c!`
error: invalid character `'§'` in crate name: `s_h.w§c!`
error: invalid character `'!'` in crate name: `s_h.w§c!`
error: could not compile `s-h-w-c-` (bin "s-h.w§c!") due to 3 previous errors
```
I decided to not get into what are or aren't valid characters according to rustc.
- `cargo pkgid` is unsupported because we can't (yet) generate valid
pkgids for embedded manifests. Adding support for this would be a
step towards workspace support
- `cargo package` and `cargo publish` are being deferred. These would
be more important for `[lib]` support. `cargo install` for `[[bin]]`s
is a small case and As single-file packages are fairly restrictive, a
`[[bin]]` is a lower priority.
The goal is that we shouldn't interefere with end-user output when
"cargo script"s are used programmatically. The only way to detect this
is when piping. CI will also look like this.
My thought is that if someone does want to do `#!/usr/bin/env -S cargo -v`, it
should have a consistent meaning between local development
(`cargo run --manifest-path`) and "script mode" (`cargo`), so I
effectively added a new verbosity level in these cases. To get normal
output in all cases, add a `-v` like the tests do. Do `-vv` if you want
the normal `-v` mode. If you want it always quiet, do `--quiet`.
I want to see the default verbosity for interactive "script mode" a bit
quieter to the point that all normal output cargo makes is cleared before
running the built binary. I am holding off on that now as that could
tie into bigger conversations / refactors
(see https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/Re-thinking.20cargo's.20output).
fix(script): Process config relative to script, not CWD
### What does this PR try to resolve?
This is part of the work for #12207.
When you put in your path `foo.rs`:
```rust
#!/usr/bin/env cargo
fn main() {}
```
You expect it to build once and then repeatedly run the same version. However, `.cargo/config.toml` doesn't work like that (normally). It is an environment file, like `.env`, and is based on your current working directory. So if you run `foo.rs` from within a random project, it might rebuild due to RUSTFLAGS in `.cargo/config.toml`.
I had some concern about whether this current behavior is right or not and [noted this in the Pre-RFC](https://github.com/epage/cargo-script-mvs/blob/main/0000-cargo-script.md#unresolved-questions). This came up again while we were [discussing editions on zulip](https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/cargo.20script.20and.20edition). In looking further into this, it turns out we already have precedence for this with `cargo install --path <path>`.
### How should we test and review this PR?
The second commit has the fix, the docs, and a change to a test (from the first commit) to show that the fix actually changed behavior.
This is to avoid possible name collisions. For example, a user
creates a file called `.cargo/cache`, and then in the future
cargo wants to create a directory called `.cargo/cache/`, that
would collide with what the user specified. Restricting to `.toml`
extensions would avoid that since we won’t make a directory named
with a `.toml` extension.
fix: Allow embedded manifests in all commands
### What does this PR try to resolve?
This is a part of #12207.
One of the goals is for embedded manifests to be a first class citizen. If you have a script, you should be able to run tests on it, for example.
This expands the error check from just `Cargo.toml` to also single-file packages so you can use it in `--manifest-path`.
This, however, does mean that these *can* be used in places that likely won't work yet, like `cargo publish`.
### How should we test and review this PR?
By commit. We introduce tests for basic commands and then implement and refine the support for this.
### Additional information
Other information you want to mention in this PR, such as prior arts,
future extensions, an unresolved problem, or a TODO list.
feat(cli): Support `cargo Cargo.toml`
### What does this PR try to resolve?
This is making the assumption that we want full unity between places accepting both single-file packages and `Cargo.toml` for #12207. This has not been brought up before in any of the discussions (Internals, eRFC), so I can understand if there are concerns about this and we decide to hold off.
We might want to resolve symlinks before this so people can have a prettier name for these.
### How should we test and review this PR?
The test for this was added in a commit before the actual change, letting people see how the behavior changed.
I originally centralized the error reporting until I realized it likely
is intentionally not centralized so we report errors in terms of the
arguments the user provided.
This puts the lockfile back into a target directory in the users home,
like before #12268.
Another idea that came up was to move the workspace root to be in the
target directory (which would effectively be like pre-#12268) but I
think that is a bit hacky / misleading.
This does mean that the lockfile is buried away from the user and they
can't pass it along with their script. In most cases I've dealt with,
this would be fine. When the lockfile is needed, they will also most
likely have a workspace, so it shoud have a local lockfile in that case.
The inbetween case is something that needs further evaluation for
whether we should handle it and how.
Enable `doctest-in-workspace` by default
This stabilizes and enables the `-Z doctest-in-workspace` flag by default.
Also adds another testcase to make sure that the `include!()` and `file!()` macros interact well together.
fixes#9427
fixes https://github.com/rust-lang/rust/issues/46372
This stabilizes and enables the `-Z doctest-in-workspace` flag by default.
Also adds another testcase to make sure that the `include!()` and `file!()` macros interact well together.
fix(embedded): Don't auto-discover build.rs files
With #12268, we moved the manifest root to be the scripts parent
directory, making it so auto-discovery might pick some things up.
We previously ensured `auto*` don't pick things up but missed `build.rs`
This is now addressed.
fix(embeded): Don't pollute the scripts dir with `target/`
### What does this PR try to resolve?
This PR is part of #12207.
This specific behavior was broken in #12268 when we stopped using an intermediate
`Cargo.toml` file.
Unlike pre-#12268,
- We are hashing the path, rather than the content, with the assumption
that people change content more frequently than the path
- We are using a simpler hash than `blake3` in the hopes that we can get
away with it
Unlike the Pre-RFC demo
- We are not forcing a single target dir for all scripts in the hopes
that we get #5931
### How should we test and review this PR?
A new test was added specifically to show the target dir behavior, rather than overloading an existing test or making all tests sensitive to changes in this behavior.
### Additional information
In the future, we might want to resolve symlinks before we get to this point
With #12268, we moved the manifest root to be the scripts parent
directory, making it so auto-discovery might pick some things up.
We previously ensured `auto*` don't pick things up but missed `build.rs`
This is now addressed.
