fix(embedded): Don't create an intermediate manifest
### What does this PR try to resolve?
More immediately, this is to unblock rust-lang/rust#112601
More generally, this gets us away from hackily writing out an out-of-line manifest from an embedded manifest. To parse the manifest, we have to write it out so our regular manifest
loading code could handle it. This updates the manifest parsing code to
handle it.
This doesn't mean this will work everywhere in all cases though. For
example, ephemeral workspaces parses a manifest from the SourceId and
these won't have valid SourceIds.
As a consequence, `Cargo.lock` and `CARGO_TARGET_DIR` are changing from being next to
the temp manifest to being next to the script. This still isn't the
desired behavior but stepping stones.
### How should we test and review this PR?
A Commit at a time
### Additional information
In production code, this does not conflict with #12255 (due to #12262) but in test code, it does.
refactor(embedded): Switch to `syn` for parsing doc comments
This is a follow up to #12245 which is working to resolve#12207
The hope is this will result in more resilient comment handling, being more consistent with rustdoc.
I also hoped for less code but `syn` is doing less than I had expected, requiring us to copy code over from other parts of rust. It seems every proc macro has to do this but there is no guide to it, so they all do it differently, only covering the cases they thought to test for.
Note that this still won't support `include_str!()`.
To parse the manifest, we have to write it out so our regular manifest
loading code could handle it. This updates the manifest parsing code to
handle it.
This doesn't mean this will work everywhere in all cases though. For
example, ephemeral workspaces parses a manifest from the SourceId and
these won't have valid SourceIds.
As a consequence, `Cargo.lock` and `CARGO_TARGET_DIR` are changing from being next to
the temp manifest to being next to the script. This still isn't the
desired behavior but stepping stones.
This also exposes the fact that we didn't disable `autobins` like the
documentation says we should.
fix(embedded): Align package name sanitization with cargo-new
### What does this PR try to resolve?
This is a follow up to #12245 which is working to resolve the tracking issue #12207
This first aligns sanitization of package names with the central package name validation logic, putting the code next to each other so they can more easily stay in sync.
Oddly enough, cargo-new is stricter than our normal package-name validation. I went ahead and sanitized along with that as well.
In working on this, I was bothered by
- the mix of `-` and `_` in file names because of sanitization, so I made it more consistent by detecting which the user is using
- -using `_` in bins, so I switched the default to `-`
### How should we test and review this PR?
One existing test covers a variety of sanitization needs
Another existing test hit one of the other cases (`test` being reserved)
### Additional information
For implementation convenience, I changed the directory we write the manifest to. The impact of this should be minimal since
- We reuse the full file name, so if it worked for the user it should work for us
- We should be moving away from the temp manifest in future commits
Clarify the default behavior of cargo-install.
The man page for `cargo install` is not explicit about what the default behavior is. This is important to clarify because `examples/` are typically unneeded and may not be maintained with the same care as "real" binaries, so it should be clear to users that example binaries won't be installed without directly asking for them.
Small doc-only update, hopefully this is acceptable. Please let me know if I need to seek further approval first (and, if so, apologies for the noise).
The hope is this will result in more resilient comment handling, being
more consistent with rustdoc.
I also hoped for less code but `syn` is doing less than I had expected,
requiring us to copy code over from other parts of rust. It seems every
proc macro has to do this but there is no guide to it, so they all do it
differently, only covering the cases they thought to test for.
Note that this still won't support `include_str!()`.
fix(embedded): Don't append hash to bin names
### What does this PR try to resolve?
More immediately, this is to unblock rust-lang/rust#112601
The hash existed for sharing a target directory. That code isn't
implemented yet and a per-user build cache might remove the need for it,
so let's remove it for now and more carefully weigh adding it back in.
In general, this is also the more appropriate way for a feature that would be first class.
### How should we test and review this PR?
This originally built on #12268 but now stands alone as the other PR has windows issues to work out
### Additional information
Background: the hash existed for sharing a target directory. That code isn't
implemented yet and a per-user build cache might remove the need for it,
so let's remove it for now and more carefully weigh adding it back in.
Immediate: This reduces the chance of hitting file length issues on Windows.
Generally: This is a bit hacky and for an official solution, we should
probably try to find a better way. This could become more important as
single-file packages are allowed in workspaces.
Fix version requirement example in Dependency Resolution, SemVer compatibility section
I additionally verified with `dtolnay/semver` crate (which it seems cargo itself uses) that version `1.2.0` really matches `>=1.2, <1.5` version requirement.
Show a better error when container tests fail.
This adds a better error message when a container test fails to build a container.
Previously the output would look something like:
```
---- ssh::ssh_key_in_config stdout ----
SSH_AGENT_PID=69284
thread 'ssh::ssh_key_in_config' panicked at 'called `Result::unwrap()` on an `Err` value: PoisonError { .. }', crates/cargo-test-support/src/containers.rs:97:39
```
Now it looks like:
```
---- ssh::ssh_key_in_config stdout ----
SSH_AGENT_PID=44281
thread 'ssh::ssh_key_in_config' panicked at 'previous docker build failed, unable to run test', crates/cargo-test-support/src/containers.rs:97:51
```
refactor(embedded)
### What does this PR try to resolve?
This is trying to make it easier to have multiple active PRs touching `embedded.rs` by separating out the parts of the code that will be touched in each PR. This is done by making the code roughly follow how the future code will be structured.
e.g. see #12255
### How should we test and review this PR?
Commit at a time. This is just a refactor, so no tests are changed.
docs: clarify the use of `default` branch instead of `main` by default
Update specifying-dependencies.md to show not specifying the branch for git doesn't always use the main branch.
feat: Initial support for single-file packages
### What does this PR try to resolve?
This is the first step towards #12207. In particular, this focuses on pulling in the [demo](https://github.com/epage/cargo-script-mvs) roughly as-is to serve as a baseline for further PRs. I have a couple months of runtime (multiple times a week) using the version of the demo included here.
### How should we test and review this PR?
Commit-by-commit. Most likely, the last (docs) commit should be done first to provide context for the others.
Naming is hard. I came up with these terms just so we can have ways to refer to them. Feedback is welcome.
- `-Zscript` for this general feature (not great but didn't want to spend too long coming up with a throwaway name)
- "single-file package": Rust code and a cargo manifest in a single file
- "embedded manifest": the explicit manifest inside of a single-file package
- "manifest command": when we interpret `cargo <name>` as referring to a single-file package, and similar to "built-in commands" and "external commands".
Keep in mind that this is a very hacky solution with many deficiencies and is mostly starting as a baseline for implementing and reviewing those improvements, including
- Switching from `regex` to `syn` for extracting manifests for greater resilience
- Matching `cargo new`s logic when sanitizing the inferred package name
- Allowing `cargo <name>` to also be a `Cargo.toml` file (for consistency in where manifests are accepted)
- Allowing single-file packages to be used wherever a manifest is accepted
To minimize conflict pain, I would ask that we consider what feedback can be handled in a follow up (though still mention it!). It'll be much easier creating multiple, independent PRs once this baseline is merged to address concerns.
### Additional information
The only affect for people on stable is that they may get a warning if they have an external subcommand that will be shadowed when this feature is implemented. This will allow us to collect feedback, without blocking people, so we can have an idea of how "safe" our precedence scheme is for interpreting `cargo <name>`.
As of right now, aliases with a `.` in them will be ignored (well, technically their suffix will be exposed as an alias). We directly inject the name into a lookup string into the config that uses `.` as the separator, so we drill down until we get to the leaf element. Ideally, we would be generating / parsing the lookup key using TOML key syntax so we can better report that this won't be supported after this change :)
This is written to reflect the current implementation though some parts
might read a little weird because I didn't want to write throw-away
documentation for when we change this. For example, single-file
packages are currently only supported in `cargo <command>` and not as
manifest paths but this will change.
