1.83 update #8
Closed
1.83 update #8
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Co-authored-by: Tor Hovland <55164+torhovland@users.noreply.github.com> Co-authored-by: Ed Page <eopage@gmail.com>
We were correctly doing this for cases like `cargo new foo` or `cargo new deeper/than/this/directory/foo` but not `cargo new ../foo`. This came up when discussing rust-lang#14501
…d, r=epage Publish workspace Adds support for simultaneously publishing multiple (possibly inter-dependent) packages in a workspace, gated by the `-Zpackage-workspace` flag. Questions to be worked out through stabilization: - Are we ok stabilizing this and rust-lang#10948 at the same time? Currently, they are behind the same flag - What is the desired behavior for the publish timeout? This PR uploads the crates in batches (depending on the dependency graph), and we only timeout if nothing in the batch is available within the timeout, deferring the rest to the next wait-for-publish. So for example, if you have packages `a`, `b`, `c` then we'll wait up to 60 seconds and if only `a` and `b` were ready in that time, we'll then wait another 60 seconds for `c`. - What is the desired behavior when some packages in a workspace have `publish = false`? This PR raises an error whenever any of the selected packages has `publish = false`, so it will error on `cargo publish --workspace` in a workspace with an unpublishable package. An alternative interface would implicitly exclude unpublishable packages in this case, but still error out if you explicitly select an unpublishable package with `-p package-name` (see rust-lang#14356). This PR's behavior is the most conservative one as it can change from an error to implicit excludes later. This is part of rust-lang#1169
RFC: rust-lang/rfcs#3529 Tracking Issue: rust-lang#14355 This PR adds the `--base` option to `cargo add` to allow adding a path dependency with a path base.
Implement path-bases (RFC 3529) 2/n: `cargo [add|remove|update]` support RFC: rust-lang/rfcs#3529 Tracking Issue: rust-lang#14355 This PR adds the `--base` option to `cargo add` to allow adding a path dependency with a path base.
bail before packaging on same version Fixes rust-lang#3662. Cleaned up commits from rust-lang#14338.
In rust-lang#13308, we decided to make the feature gate for public/private dependencies non-blocking. Generally, people opt-in to a feature that is non-blocking through `-Z` but some nightly users want an "always on" mode for this, so we offered both in rust-lang#13340. In rust-lang#13340, we made both feature gates work but we did not make them non-blocking for stable, only nightly. This change makes the feature gate non-blocking on stable.
fix(toml): Don't require MSRV bump for pub/priv ### What does this PR try to resolve? In rust-lang#13308, we decided to make the feature gate for public/private dependencies non-blocking. Generally, people opt-in to a feature that is non-blocking through `-Z` but some nightly users want an "always on" mode for this, so we offered both in rust-lang#13340. In rust-lang#13340, we made both feature gates work but we did not make them non-blocking for stable, only nightly. This change makes the feature gate non-blocking on stable. Unfortunately, this means that 1.83 will be the MSRV for people using public dependencies. Good thing the feature is indefinitely blocked in rustc as that gives us more time. ### How should we test and review this PR? ### Additional information
This change introduces a new method, `Dependency::serialized` which replaces the direct `Serialize` implementation on `Dependency`. This matches the pattern used by `Package` with its `Package::serialized`, and will enable us to influence the serialization format with additional arguments. I replaced borrowed types in `SerializedDependency` with owned variants to satisfy the borrow checker. This matches `SerializedPackage` and shouldn't be an issue since `Dependency` is cheap to copy.
This commit clarifies the doc by stating we can place a binary source as `src/main.rs` and/or in `src/bin/`. Wording is suggested by Ed Page (@epage). Closes rust-lang#14463.
…=weihanglo docs: bin source can be `src/main.rs` and/or in `src/bin/` ### What does this PR try to resolve? This commit clarifies the doc by stating we can place a binary source as `src/main.rs` and/or in `src/bin/`. Wording is suggested by Ed Page (`@epage).` ### How should we test and review this PR? (It seems the only way is to check the chenge visually...) ### Additional information Closes rust-lang#14463.
Signed-off-by: cuishuang <imcusg@gmail.com>
Remove unnecessary symbols
Include public/private dependency status in `cargo metadata` fixes rust-lang#14502 > [!TIP] > This change can be reviewed commit-by-commit. > Descriptions on individual commits are available to justify some decisions `@rustbot` label Command-metadata Z-public-dependency
…, r=weihanglo Fix parsing of comma separated values in --crate-type flag ### What does this PR try to resolve? According to the documentation the `--crate-type` flag accepts a comma separated list of crate types. However, these are never actually split into individual items and passed verbatim to rustc. Since cargo fails to associate cases such as 'staticlib,cdylib' to a specific crate type internally, it has to invoke rustc to determine the output file types for this unknown crate type, which returns only the first file type of the first crate type in the list. Consequently cargo will be looking only for a single '.a' artifact on Linux to be copied to the target directory. Fix this by splitting the list of provided crate types into individual items before further processing them. Fixes rust-lang#14498 ### How should we test and review this PR? Updated corresponding test cases ### Additional information
fix(new): Add to workspace relative to manifest, not current-dir ### What does this PR try to resolve? We were correctly doing this for cases like `cargo new foo` or `cargo new deeper/than/this/directory/foo` but not `cargo new ../foo`. This came up when discussing rust-lang#14501 ### How should we test and review this PR? ### Additional information
Document build-plan as being deprecated This adds a note to the build-plan documentation that it is deprecated. I do not think it will make any progress as it is. In the future, we should remove the feature (rust-lang#7902), possibly with a code-warning ahead of time.
…eter, r=epage feat: Add custom completer for completing registry name ### What does this PR try to resolve? Tracking issue rust-lang#14520 Add custom completer for completing `cargo publish --registry <TAB>` and `cargo add --registry <TAB>`.
* cargo_env_changes * fingerprint_cleaner_does_not_rebuild * modify_only_some_files * rebuild_if_build_artifacts_move_forward_in_time * simulated_docker_deps_stay_cached * update_dependency_mtime_does_not_rebuild
These tests are modified or renamed to reflect the switch to checksum fingerprint: * bust_patched_dep * modifying_and_moving * rebuild_on_mid_build_file_modification * rebuild_sub_package_then_while_package * skip_mtime_check_in_selected_cargo_home_subdirs * use_mtime_cache_in_cargo_home
We don't rely on mtime anymore for checksum-based fingerprint
Two new tests: * checksum_actually_uses_checksum: chekcsum works when mtime forwards * same_size_different_content: checksum does check content
This ensures that users can switch between different fingerprint freshness methods and still correctly rebuild stuff.
initial version of checksum based freshness Implementation for rust-lang#14136 and resolves rust-lang#6529 This PR implements the use of checksums in cargo fingerprints as an alternative to using mtimes. This is most useful on systems with poor mtime implementations. This has a dependency on rust-lang/rust#126930. It's expected this will increase the time it takes to declare a build to be fresh. Still this loss in performance may be preferable to the issues the ecosystem has had with the use of mtimes for determining freshness.
This will get cherry-picked to beta Fixes rust-lang#14721
[beta-1.83] fix(publish): Downgrade version-exists error to warning on dry-run Beta backports * rust-lang#14742 In order to make CI pass, the following PRs are also cherry-picked: *
When -Z build-std is used, patch compiler-builtins so that our own fork is downloaded. Needed for solana-labs/solana#23465.
|
IFAICT, the introduction of rust-lang/rust#128534 and rust-lang#14358 makes the injection of the in-house @LucasSte I will stop at the current number of repositories because it would take too much time to tackle LLVM. Let me know if everything else is OK. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The main update is the fact that the project is no longer using a virtual workspace to build the standard library.
I still need to confirm if such a thing is responsible for surpassing the old git patch warnings.