docs(unstable): Point stable-unstable docs to nightly docs
I ran into this in trying to find the "cargo script" docs. Unless its the rare case of `RUSTC_BOOTRAP=1 cargo +stable ...`, someone reading about features on `+nightly` likely would want to see the latest version of this document, so we should help people find it.
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.
Convert valid feature name warning to an error.
This converts the feature name validation check from a warning to an error. This was added in #8814 in Rust 1.49 released in 2020-12-31 (about 2.5 years ago) with a warning that it will become a hard error in the future.
These extended characters aren't allowed on crates.io, so this should only impact users of other registries, or people who don't publish to a registry. The warning message requested anyone impacted by it to let us know. We got one report, and added support for . as result. Since there weren't any other reports, I think it should be pretty safe to move forward.
The diff here is a little large because it removes the pass-through of `config` since it isn't needed anymore.
Additionally, the tests were restructured since testing every edge case in an integration test has a lot of overhead. Instead, there is now a unit test which runs much faster, with the integration test just verifying that it fires and checks the two forms of error messages.
Closes#8813
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.
fix(embedded): Don't pollute script dir with lockfile
### What does this PR try to resolve?
This puts the lockfile back into a target directory in the users home,
like before https://github.com/rust-lang/cargo/pull/12268.
Another idea that came up was to move the workspace root to be in the
target directory (which would effectively be like pre-https://github.com/rust-lang/cargo/pull/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.
### How should we test and review this PR?
Its a bit difficult to test for the lockfile in the new location, so this is mostly being tested in that the lockfile no longer exists next to the script.
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 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.
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.
