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.
The `-Znext-lockfile-bump` is added, so we can prepare for all
lockfile format changes and then stabilize then all at once.
`-Znext-lockfile-bump` is not intended for using outside our test
suite and development. Hence it's hidden.
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!()`.
This 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
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.
