`obj` is already `&T`.
<!--
Thanks for submitting a pull request 🎉! Here are some tips for you:
* If this is your first contribution, read "Cargo Contribution Guide"
first:
https://doc.crates.io/contrib/
* Run `cargo fmt --all` to format your code changes.
* Small commits and pull requests are always preferable and easy to
review.
* If your idea is large and needs feedback from the community, read how:
https://doc.crates.io/contrib/process/#working-on-large-features
* Cargo takes care of compatibility. Read our design principles:
https://doc.crates.io/contrib/design.html
* When changing help text of cargo commands, follow the steps to
generate docs:
https://github.com/rust-lang/cargo/tree/master/src/doc#building-the-man-pages
* If your PR is not finished, set it as "draft" PR or add "WIP" in its
title.
* It's ok to use the CI resources to test your PR, but please don't
abuse them.
### What does this PR try to resolve?
Explain the motivation behind this change.
A clear overview along with an in-depth explanation are helpful.
You can use `Fixes #<issue number>` to associate this PR to an existing
issue.
### How should we test and review this PR?
Demonstrate how you test this change and guide reviewers through your
PR.
With a smooth review process, a pull request usually gets reviewed
quicker.
If you don't know how to write and run your tests, please read the
guide:
https://doc.crates.io/contrib/tests
### Additional information
Other information you want to mention in this PR, such as prior arts,
future extensions, an unresolved problem, or a TODO list.
-->
### What does this PR try to resolve?
Remap all paths pointing to `build.build-dir`,
i.e., `[BUILD_DIR]/debug/deps/foo-[HASH].dwo` would be remapped to
`/cargo/build-dir/debug/deps/foo-[HASH].dwo`
(note the `/cargo/build-dir` prefix).
This covers scenarios like:
* Build script generated code. For example, a build script may call
`file!`
macros, and the associated crate uses `include!` to include the expanded
`file!` macro in-place via the `OUT_DIR` environment.
* On Linux, `DW_AT_GNU_dwo_name` that contains paths to split debuginfo
files (dwp and dwo).
### How to test and review this PR?
Should be quite straightforward.
The open question is what we want to remap _to_, to help debugger to
find the source files.
cc #12137 and #13171
Remap all paths pointing to `build.build-dir`,
i.e., `[BUILD_DIR]/debug/deps/foo-[HASH].dwo` would be remapped to
`/cargo/build-dir/debug/deps/foo-[HASH].dwo`
(note the `/cargo/build-dir` prefix).
This covers scenarios like:
* Build script generated code. For example, a build script may call `file!`
macros, and the associated crate uses [`include!`] to include the expanded
[`file!`] macro in-place via the `OUT_DIR` environment.
* On Linux, `DW_AT_GNU_dwo_name` that contains paths to split debuginfo
files (dwp and dwo).
### What does this PR try to resolve?
Before this some end-to-end tests didn't cover Windows platforms.
After this, we cover windows-msvc for
* End-to-end debugger tests.
* Check path is trimmed with symbol viewers like `strings`.
windows-gnu isn't covered
### How to test and review this PR?
There are things needing attentions:
* This adds a new CI job for window-msvc "nightly" toolchain.
* In 2f923b3ff25f847d we don't check if an executable's availability by
running `<cmd> --version`. Instead, we check the file execute bit.
* Enabled windows-msvc tests rely on the software provided by [GitHub
windows runner
image](e330e24b7e/images/windows/Windows2022-Readme.md)
* Windows SDK which provides cdb and other debugger tools
* `strings` is provided by MinGW.
### What does this PR try to resolve?
This was discovered during playing with rmeta reuse between cargo-check
and cargo-build.
An rmeta mtime failure is basically the same as "failed to read
metadata".
While we don't report in tracing log, that should be fine because dirty
reason will be reported in the other place.
### How to test and review this PR?
Should have no real user-facing behavior change.
GitHub Actions has Windows SDK pre-installed,
so cdb should be available at that path always.
Additionally, this adds a new CI job for windows-msvc nightly toolchain
Not every executable has a `--version` flag.
Let's check the exectuability instead.
Note that on Windows we check if it is file only.
There is a `is_executable` crate on crates.io,
though that still depend on winapi so don't bother using it.
### What does this PR try to resolve?
This PR fixes a bug where `cargo add` breaks symlinks to Cargo.toml
files. Currently, when Cargo.toml is a symlink and `cargo add` is used
to add a dependency, the symlink is replaced with a regular file,
breaking the link to the original target file.
This issue was reported in #15241 where a user who relies on symlinked
Cargo.toml files found that `cargo add` breaks their workflow.
Fixes#15241
### How should we test and review this PR?
I've modified `LocalManifest::write()` to check if the path is a
symlink, and if so, follow it to get the actual target path. This
ensures we write to the actual file rather than replacing the symlink.
I've also added a test in `tests/testsuite/cargo_add/symlink.rs` that:
1. Creates a symlinked Cargo.toml file
2. Runs `cargo add` to add a dependency
3. Verifies the symlink is preserved and the dependency is added to the
target file
I've manually tested this fix and confirmed it works correctly.
- Preserve symlinks when writing files atomically in write_atomic()
- Update test to verify correct symlink preservation behavior
- Apply rustfmt formatting
This fixes the issue where cargo add would replace symlinked Cargo.toml
files with regular files, breaking the symlink to the original target.
Fixes#15241
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| alpine | final | minor | `3.21` -> `3.22` |
---
### Configuration
📅 **Schedule**: Branch creation - "before 5am on the first day of the
month" (UTC), Automerge - At any time (no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR was generated by [Mend Renovate](https://mend.io/renovate/).
View the [repository job
log](https://developer.mend.io/github/rust-lang/cargo).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0MC4zMy42IiwidXBkYXRlZEluVmVyIjoiNDAuMzMuNiIsInRhcmdldEJyYW5jaCI6Im1hc3RlciIsImxhYmVscyI6W119-->
### What does this PR try to resolve?
The HTML comments in the PR template, after this repo migrated to GitHub
merge queue, often show up in the merge commit message when people
forgot to delete it.
This PR removes those, as they are only important for people never look
at the contributor guide. We keep one link to the guide though at the
top of the template.
It also moves the entire template out of HTML comments, so it is more
obvious for maintainers to see what will be in the merge commit message.
The “Additional information” paragraph is removed, as I observed it is
seldom used.
### How to test and review this PR?
Copy and paste the PR template into the PR description preview, and see
if it satisfies your eyes.
This adds a file to ignore most formatting commits in `git blame`. These
commits usually are not interesting, and being able to skip them makes
it a little easier to traverse a blame history. This is a feature
natively supported by GitHub automatically to ignore these. When running
locally, you need to first configure git to use it.
I was a little on the fence on which PRs to include here. Many of these
are small and probably not too important. However, instead of trying to
figure out some threshold of "is this large enough", I decided to just
include all of them.
I checked these by visually looking at each commit and briefly checking
that it didn't seem to include any non-formatting changes.
I think it would be nice to try to keep commits a little cleaner in the
future, and avoid merging PRs that have things like this (unless it is
due to a change in rustfmt itself). I admit I don't always enforce it
since it can be a significant drag, though.
### What does this PR try to resolve?
Some more cleanup after #15601
See each commit message for details.
### How should we test and review this PR?
Help review whether it has really no behavior change.
This adds a file to ignore most formatting commits in `git blame`. These
commits usually are not interesting, and being able to skip them makes
it a little easier to traverse a blame history. This is a feature
natively supported by GitHub automatically to ignore these. When running
locally, you need to first configure git to use it.
I was a little on the fence on which PRs to include here. Many of these
are small and probably not too important. However, instead of trying to
figure out some threshold of "is this large enough", I decided to just
include all of them.
I checked these by visually looking at each commit and briefly checking
that it didn't seem to include any non-formatting changes.
I think it would be nice to try to keep commits a little cleaner in the
future, and avoid merging PRs that have things like this (unless it is
due to a change in rustfmt itself). I admit I don't always enforce it
since it can be a significant drag, though.
`cargo test` will implicitly build examples as examples binaries
(without --test) by default, when no target selection flags provided.
We don't have test exercising this, so add one.
This test shows the current behavior where cargo add replaces
symlinked Cargo.toml files with regular files. The test passes,
documenting this problematic behavior.
To justify why it won't affect any existing behavior:
* For the default set of Cargo targets,
test/bench targets would only be selected by `cargo test`,
whose UserIntent will turn into `CompileMode::Test`,
but never `CompileMode::Build`.
* For selective Cargo targets, i.e., `--tests`, or `--test`,
Their `CompileMode` would either be `Check { test }` or `Test`.
They will never be `Build`.
See https://github.com/rust-lang/cargo/blob/bffece899e9/src/cargo/ops/cargo_compile/unit_generator.rs#L450-L465
According to these facts, there won't be a case that
bench/test targets get assigned to `CompileMode::Build`.
### What does this PR try to resolve?
This separates the concern of two different "mode".
- UserIntent: focus on the overall goal of the build
- CompileMode: the actual compile operation for each unit (I'd like to
rename it to something else in the future, such as CompileAction)
This is a preparation of adding `-Zno-link`/`-Zlink-only` support,
which we'll have `CompileMode::Link` but that doesn't make sense to
show up in `UserIntent`.
### How should we test and review this PR?
It should have no functional change.
### Additional information
### What does this PR try to resolve?
Fixes#15604
rustdoc assumes to add static files only when the
toolchain-shared-resources emit-type is specified, or when no emit-type
is specified.
See
80c34983c6/src/librustdoc/html/render/write_shared.rs (L206-L213)
### How should we test and review this PR?
Not going to write a test because I don't think we want to inspect into
how rustdoc arranges static files.
See #15604 for how to reproduce/test.
### Additional information
cc #15370
### What does this PR try to resolve?
This pulls in the tests from rust-lang/rust#140035 and ensures we pass
them, including switching our parser to be more like the one from
rust-lang/rust#137193.
I've added comments specifying why our test results differ from rustcs.
This is part of #12207
### How should we test and review this PR?
### Additional information
We still have work to do to improve the quality of our error messages
### What does this PR try to resolve?
0.9.0 may look like a downgrade but the maintainer has decided to go
back to `0.x` versions rather than continuing to use pre-release
versions
### How should we test and review this PR?
### Additional information
This separates the concern of two different "mode".
- UserIntent: focus on the overall goal of the build
- CompileMode: the actual compile operation for each unit
This is a preparation of adding `-Zno-link`/`-Zlink-only` support,
which we'll have `CompileMode::Link` but that doesn't make sense to
show up in `UserIntent`.
This adds a new `cargo fix -Zfix-edition` permanently unstable flag to
assist with edition migration testing, particularly with crater.
The commits and given documentation should explain how it works, but
there will be forthcoming edition documentation (on the forge) once all
the pieces with crater come together.
This adds the `EditionFixMode` enum to control the behavior of
`cargo fix --edition`. The main intent is to provide a way to force
`cargo fix` to migrate to a specific edition, instead of just going to
the "next".
This will be needed for `-Zfix-edition` in order to force it to use the
"future" edition, which is never the "next" edition.
This requires being able to serialize and deserialize this setting as it
is conveyed through an environment variable to the recursive cargo
invocation.
This factors out the code to reload a workspace since I will be needing
to reuse this elsewhere.
There is some risk with this method not getting updated correctly in the
future as new fields are added to Workspace (and it may be missing some
things now), but that is an issue with the existing code.
### What does this PR try to resolve?
This reduces the build time of `cargo-util-schemas` by disabling the
unused `display` and `parse` features of `toml` (which are enabled by
default).
This is useful as `cargo-util-schemas` is intended to be reused outside
of Cargo.
### How should we test and review this PR?
As I believe these features only *feature-gate* items on `toml` (they do
not affect runtime behavior silently), the CI building successfully
should be enough to make sure this does not break anything. ~If this
does not build, I will try to tend to it today, otherwise feel free to
push to this branch.~
<!--
Thanks for submitting a pull request 🎉! Here are some tips for you:
* If this is your first contribution, read "Cargo Contribution Guide"
first:
https://doc.crates.io/contrib/
* Run `cargo fmt --all` to format your code changes.
* Small commits and pull requests are always preferable and easy to
review.
* If your idea is large and needs feedback from the community, read how:
https://doc.crates.io/contrib/process/#working-on-large-features
* Cargo takes care of compatibility. Read our design principles:
https://doc.crates.io/contrib/design.html
* When changing help text of cargo commands, follow the steps to
generate docs:
https://github.com/rust-lang/cargo/tree/master/src/doc#building-the-man-pages
* If your PR is not finished, set it as "draft" PR or add "WIP" in its
title.
* It's ok to use the CI resources to test your PR, but please don't
abuse them.
### What does this PR try to resolve?
Explain the motivation behind this change.
A clear overview along with an in-depth explanation are helpful.
You can use `Fixes #<issue number>` to associate this PR to an existing
issue.
### How should we test and review this PR?
Demonstrate how you test this change and guide reviewers through your
PR.
With a smooth review process, a pull request usually gets reviewed
quicker.
If you don't know how to write and run your tests, please read the
guide:
https://doc.crates.io/contrib/tests
### Additional information
Other information you want to mention in this PR, such as prior arts,
future extensions, an unresolved problem, or a TODO list.
-->
### What does this PR try to resolve?
When Cargo's changelog was moved into the book in #15123, it seems the
extension was left as `.md`, whereas the link should point to the
rendered version, which ends with `.html`.
### How should we test and review this PR?
Following the new link in the README's rendered view and observing that
it does indeed point to the changelog should be enough.
This adds support for the "future" edition which was added to rustc in
https://github.com/rust-lang/rust/pull/137606.
To enable support for unstable editions, this introduces a new
`unstable-editions` cargo feature. The intent is that instead of having
a new feature for each edition that we reuse this feature for all new
editions. I don't see a particular reason we should have a separate one
for each edition, and this helps a bit with scalability and simplifies
some of the edition process.
This also includes a change to rework `supports_compat_lint` explained
in the comment.
This adds support for the "future" edition which was added to rustc in
https://github.com/rust-lang/rust/pull/137606.
To enable support for unstable editions, this introduces a new
`unstable-editions` cargo feature. The intent is that instead of having
a new feature for each edition that we reuse this feature for all new
editions. I don't see a particular reason we should have a separate one
for each edition, and this helps a bit with scalability and simplifies
some of the edition process.
This also includes a change to rework `supports_compat_lint` explained
in the comment.
### What does this PR try to resolve?
We aren't quite ready for writing lints (waiting on an annotate-snippets
release) but I wanted to start recording some lint ideas I had.
### How should we test and review this PR?
Based on clippy's which I assumed would be a good starting point. There
are more area we'll need to fill out during discussion, like the lint
name, what primary group the lint would be in, etc.
### Additional information
