synced #3
Merged
synced #3
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
refactor: de-depulicate `make_dep_prefix` implementation
chore: detect the channel a PR wants to merge into ### What does this PR try to resolve? This detects which channel a pull request wants to merge into. It is hard because bors runs in a different repo. Bors knows nothing about branches or tag in this repo. It only see one base commit and a merge commit AFAIK. Basically the assumption and idea are 1. bors create a merge commit, so `HEAD~` should find the base branch. 2. Cargo maintains `rust-1.y.0` branch for each Rust minor version releases. Therefore, we can use the symbolic name of `origin/rust-1.x.0` to determine if it aims for stable, beta, or nightly channel. 3. After we know which channel it is targeted at, we can skip jobs that are likely to be broken.
Previously, `Debuginfo::None` meant "don't pass -C debuginfo" and `Explicit(None)` meant
"-C debuginfo=0", which occasionally led to caching bugs where cargo would sometimes pass
`-C debuginfo=0` and sometimes not. There are no such bugs currently that we know of, but
representing them the same within cargo avoids the possibility of the bug popping up again in the
future.
I tested the `with_stderr_does_not_contain_tests` with this diff to ensure they did not pass:
```diff
diff --git a/src/cargo/core/compiler/mod.rs b/src/cargo/core/compiler/mod.rs
index 55ec17182..c186dd00a 100644
--- a/src/cargo/core/compiler/mod.rs
+++ b/src/cargo/core/compiler/mod.rs
@@ -1073,9 +1073,7 @@ fn build_base_args(
let debuginfo = debuginfo.into_inner();
// Shorten the number of arguments if possible.
- if debuginfo != TomlDebugInfo::None {
cmd.arg("-C").arg(format!("debuginfo={}", debuginfo));
- }
cmd.args(unit.pkg.manifest().lint_rustflags());
if !rustflags.is_empty() {
```
Co-authored-by: Weihang Lo <[email protected]>
Don't distinguish `Debuginfo::None` and `Debuginfo::Explicit(None)`
Previously, `Debuginfo::None` meant "don't pass -C debuginfo" and `Explicit(None)` meant "-C debuginfo=0", which occasionally led to caching bugs where cargo would sometimes pass `-C debuginfo=0` and sometimes not. There are no such bugs currently that we know of, but representing them the same within cargo avoids the possibility of the bug popping up again in the future.
I tested the `with_stderr_does_not_contain` tests with this diff to ensure they did not pass:
```diff
diff --git a/src/cargo/core/compiler/mod.rs b/src/cargo/core/compiler/mod.rs
index 55ec17182..c186dd00a 100644
--- a/src/cargo/core/compiler/mod.rs
+++ b/src/cargo/core/compiler/mod.rs
`@@` -1073,9 +1073,7 `@@` fn build_base_args(
let debuginfo = debuginfo.into_inner();
// Shorten the number of arguments if possible.
- if debuginfo != TomlDebugInfo::None {
cmd.arg("-C").arg(format!("debuginfo={}", debuginfo));
- }
cmd.args(unit.pkg.manifest().lint_rustflags());
if !rustflags.is_empty() {
```
… r=epage Revert "chore: detect the channel a PR wants to merge into" Reverts rust-lang/cargo#12181 GitHub Action expression `success()` will look into the chain of dependent jobs. On master CI passed but on a backport it still failed <rust-lang/cargo#12200 (comment)> This isn't worth pursuing at this moment either. To fix it, it's unavoidable to write something like below for bors job ```yaml if: "always() && !(contains(needs.*.result, 'cancelled') || contains(needs.*.result, 'skipped') || contains(needs.*.result, 'failure') ) && github.event_name == 'push' && github.ref == 'refs/heads/auto-cargo' " ``` I don't think that's good in long-term. r? ehuss
Add a small note about indexes ignoring SemVer build metadata. This adds some clarification to the documentation on how registries need to handle SemVer build metadata, and the uniqueness constraint around version entries. IIRC, some issues in cargo have been fixed, but some still linger (like #7180). crates.io just fixed it so that new duplicates will be rejected.
cargo clean: use `remove_dir_all` Fixes #11441
Apparently it was a bit confusing where `rustflags` is from when reading this piece of code.
It was unnecessary to pass `spilt-debuginfo` if there is no debuginfo. Tests are touched here only for matching rustflags invocation stderr in the original test suite.
This is for linker arguments from build scripts, so should live there.
Make it clear by separating static and dynamic rustflags.
Make it clear by separating static and dynamic rustdocflags.
This was an overlook in #12205
refactor: compiler invocations
Remove a noop `.clone`
nit: fix typo in changelog for 1.70 A tiny typo
refactor: housekeeping for 1.70.0
Bump to 0.73.0; update changelog [rendered](https://github.com/weihanglo/cargo/blob/version-bump/CHANGELOG.md)
Update curl-sys This is a routine update for libcurl. Changelog: * https://curl.se/changes.html#8_1_0 * https://curl.se/changes.html#8_1_1 * https://curl.se/changes.html#8_1_2
chore: Sort `-Z` flags match statement #12182 started work on sorting/organizing things within `src/cargo/core/features.rs`. While working on #12182, I noticed that [this match statement](https://github.com/rust-lang/cargo/blob/6ec9649372a3d03958d15e96bdbf078ee50a2a71/src/cargo/core/features.rs#L1013) was not sorted very well and made things hard to find. I decided to sort the match statement in the say way as [I suggested](https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/Sorting.20features!.20and.20ensuring.20it.20stays.20sorted/near/361170201) for [`features!`](https://github.com/rust-lang/cargo/blob/6ec9649372a3d03958d15e96bdbf078ee50a2a71/src/cargo/core/features.rs#LL424C3-L424C3): - Stability (always unstable>stable>unstable) - Version stabilized (1.31>1.32) - Feature name Note: I couldn't find a way to keep this sorted as I want to do with `unstable_cli_options!` and `features!`
Fix typo in changelog
This commit adds support for passing the keyword "default"
to either the CLI "--jobs" argument on the "[build.jobs]"
section of ".cargo/config".
This is dony by:
1. Changing the "jobs" config type to an enum that holds
a String or an Integer(i.e. i32).
2. Matching the enum & casting it to an integer
Signed-off-by: Charalampos Mitrodimas <[email protected]>
Support "default" option for `build.jobs` This commit adds support for passing the keyword `default` to either the CLI `--jobs` argument on the `[build.jobs]'` section of `.cargo/config`. Closes #11816
…-and-install, r=weihanglo Emit error when users try to use a toolchain via the `add` or `install` command Running `cargo install +nightly` or `cargo add +nightly` does not actually use the nightly toolchain, but the user won't know until the compilation fails. With this PR, an error is emitted if the `install` and `add` command is given a crate name that starts with a `+` as we assume the user's intention was to use a certain toolchain instead of installing/adding a crate. Example: <img width="758" alt="image" src="https://github.com/rust-lang/cargo/assets/45989466/16e59436-32ee-49ee-9933-8b68b176c09d"> Fixes #10362
This is a writing style enforced in The Rust Standard Library.
doc: the first line should be a simple sentence instead of a heading This is a writing style enforced in The Rust Standard Library.
trvswgnr
requested review from
lleyton,
pinkforest,
sammi-turner,
dreyfus92 and
EmberHext
and removed request for
a team
trvswgnr
added a commit
that referenced
this pull request
Jul 9, 2023
commit f86b54d Merge: 8505fe0 550ccf0 Author: Travis A. Wagner <[email protected]> Date: Fri Jun 23 13:53:42 2023 -0400 Merge pull request #6 from crablang/update-readme update readme commit 8505fe0 Merge: 5889303 e181e93 Author: Sammi Turner <[email protected]> Date: Fri Jun 23 12:07:50 2023 +0100 Merge pull request #5 from crablang/trav/rename rename commit 550ccf0 Author: Travis Wagner <[email protected]> Date: Fri Jun 23 05:36:15 2023 -0400 update readme commit e181e93 Author: Travis Wagner <[email protected]> Date: Fri Jun 23 05:03:22 2023 -0400 "cargo" -> "crabgo" commit 01ab24a Author: Travis Wagner <[email protected]> Date: Fri Jun 23 04:58:34 2023 -0400 add another bin named "crabgo" with the same path changing the main bin name means modifying a lot of tests i don't see a reason to do that at this point commit 5889303 Merge: c9b89c6 57326f5 Author: Travis A. Wagner <[email protected]> Date: Mon Jun 5 03:13:07 2023 -0400 Merge pull request #3 from crablang/synced synced
trvswgnr
added a commit
that referenced
this pull request
Jul 9, 2023
* refactor: rename `location` to `path` for `GitCheckout` For being consistent with `GitDatabase`. * refactor: rename arg `orig_url` to `remote_url` for `fetch()` `orig_url` was unclear. Whose origin? `remote_url` is way more self-explanatory under a `git fetch` context. * refactor: new const `CHECKOUT_READY_LOCK` for `.cargo-ok` The explanation is moved to be public from an inline comment. * refactor: remove unused function `GitRemote::rev_for` Although this is only a few lines of code, I think it is still worth keeping it clean if it's not used by Cargo internally. Not to mention this apparently has an alternative solution at this moment, for example: ```diff - let oid = git_remote.rev_for(db_path, git_ref)?; + let oid = git_remote.db_at(db_path)?.resolve(git_ref)?; ``` From a naive research on GitHub, there is only one usage[^1] and it seems to be active but still experimental. Pardon my abrupt change breaking your project :( Only when we start considering what we want to expose can Cargo has a clearer boundaries between its subcrates. [^1]: https://github.com/trustification/source-distributed/blob/124ef26081a41330a553483441fca544bedbb473/src/git.rs#L34 * refactor: dont derive `Serialize` for git database/checkout It doesn't seem that they need to derive `Serialize`. Is there any other usage I am not aware of? * refactor: deduce path from repo for `GitCheckout` It was confusing and may lead to inconsistency that people need to pass both `path` and `repo` and ensure they are in sync. * refactor: deduce `parent_remote_url` from `database.remote.url()` This should be less controversial as the current logic share the same `GitRemote`. You can see the callsite of `GitDatabase::copy_to` use `self.url()`, which then calls into `self.remote.url(). When a `GitDatabase` is created, Cargo also uses `self.remote` as the remote of that `GitDatabase`. * test(z-flags): Verify `-Z` flags list is sorted * Add message on reusing previous temporary path on failed cargo installs * Add additional info on a new line * refactor: extract proxy detection to `cargo::util` * Upgrade to `gix` v0.45 for multi-round pack negotiations. Previously, fetches and clones would routinely fail with a panic that indicated that pack-negotiation can't take longer than 1 round with our previous `Naive` approach. With this version of `gitoxide` there is now faithful support for both the `consecutive` and the `skipping` algorithm and multiple rounds of negotiations, which should make all clones and fetches possible. * docs: add link to nightly config doc for `SourceConfigMap` * doc: point to nightly cargo doc Nightly doc contains more information and rationale for each item. It's a better fit for those want to extend Cargo's functionality. * doc: doc comments for registry module * doc: doc comments for registry index * refactor: move constants closer to where they are used This is quite straightforward. * refactor: use the term "index schema" instead of "index format" We had index format version and index file version. Both sometimes are written as "index version". This is so confusing that I need to check to source code back-and-forth. Today we make "index format version", which refers to the exact representation of a index file, rename to "index schema version". Other index file version of index version should just mean the opaque version of an index file for cache invalidation use. * refactor: move `RegistryPackage` to `index` module `RegistryPackage` is a line in a raw registyr index file. This should belong to `index.rs` module. * refactor: use `str::to_lowercase` This piece of code was written before 1.2 and `str::to_lowercase` is an API came out in Rust 1.2. * fix: disable multiplexing for bad curl In certain versions of libcurl when proxy is in use with HTTP/2 multiplexing, connections will continue stacking up. This was fixed in libcurl 8.0.0 in curl/curl@821f6e2 However, Cargo can still link against old system libcurl if it is from a custom built one or on macOS. For those cases, multiplexing needs to be disabled when those versions are detected. * test: loose overly matches for git cli output The output format should be stable I believe, but it turns out not. This is how `git fetch` man page says [1]: ``` <flag> <summary> <from> -> <to> [<reason>] ``` In Git 2.41 they've changed the fetch output a bit [2]. I think let's just loose it to prevent future breakages. [1]: https://git-scm.com/docs/git-fetch#_output [2]: https://github.blog/2023-06-01-highlights-from-git-2-41/ * refactor: rename `RegistryPackage` to `IndexPackage` This is a better name to reflect it is from "index" files. * add test case * rename `url` to `child_remote_url` * make `child_remote_url` a `Url` and pass it to `update_submodules` * remove `match` expr * use implicit arg capture and wrap line * add `Url::parse` context * remove escapes and leading whitespace from string matches * feat: Add -Zscript * refactor(cli): Allow use of both args/sub_args * feat(cli): Interpret some subcommands as manifest-commands * chore(ci): Ensure bors is blocked on clippy * chore: Migrate print-ban from test to clippy This should be more resilient to false positives like in #12245 where a string contains `println`. * docs: docs for arguments of `RegistrySource::new` * docs: fix the wrong cache directory path * docs: add a link to Cargo book for download URL template * docs: doc comments for registry downloads * docs: doc comments for local registry * docs: doc comments for remote registry * docs: doc comments for http registry * test(cli): Verify precedence over external subcommands * feat(cli): Define precedence among subcommands I decided to start things off fairly simple. It either looks like the user is specifying a manifest or they aren't. This is assuming we only need to handle `cargo foo.rs` and `cargo ./foo.rs` and not `cargo foo`. I think in most shebang cases, path multiple components will present which makes that a dead giveaway and likely to not overlap with aliases and subcommands. For reference, dlang's dub goes a lot further 1. Checks for the subcommand name being `-` 2. Checks if subcommand name ends with `.d` 3. Checks if subcommand name is built-in 4. Checks if a file with the subcommand name exists 5. Checks if a file with the subcommand name + `.d` exists This would allow a `run.d` to override `dub-run` which doesn't seem good. * refactor: unify .crate tarball name constrution * refactor: remove leftover of #6880 The relevant part was removed in 1daff03 LAST_UPDATED_FILE was never used even before #6880. They were just leftover during the PR updates. * refactor: inline `make_dep_prefix` It is not used anywhere other than in module `registry::download`. * refactor: extract `config.json` as a constant * refactor: reuse calls to try_old_curl macro At least doc duplicate can be eliminiated * fix(cli): Warn on stable for precedence changes This will give us a window to collect feedback on if this affects anyone. * refactor(cli): Pull out run error handling * refactor(cli): Align the two run's params * feat(cli): Pull in cargo-script-mvs core logic This is no where near the implementation we want but I think we should develop incrementally on top of what we already have. See https://github.com/epage/cargo-script-mvs/tree/main * docs(unstable): Expand on manifest commands so far 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. * Record results from testing Update specifying-dependencies.md to show not specifying the branch for git doesn't always use the main branch. * changelog: add 1.71 backport fix for libcurl * changelog: update for 1.72 * Update specifying-dependencies.md * Update dependencies Hand-picked some dependencies to update. Looks pretty safe? - anyhow - base64 - [email protected] - flate2 - git2 - libgit2-sys - log - openssl - pkg-config - proptest - pulldown-cmark - serde - serde_json - snapbox - tempfile - time - toml - toml_edit - url * refactor(embedded): Flatten parsing This is a step towards making it easier to implement multiple fixes / features without conflicts. * refactor(embedded): Decouple package name sanitization * refactor(embedded): Hide unused items * refactor(embedded): Centralize separator choice * Show a better error when container tests fail. * Update triagebot links. * Fix version requirement syntax example * fix(embedded): Don't append hash to bin names 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. * refactor(embedded): Switch to `syn` for parsing doc comments 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): Be consistent with existing style when sanitizing * refactor(embedded): Centralize package name rules * fix(embedded): Sanitize like we validate package names * Clarify the default behavior of cargo-install. * fix(embedded): Extend sanitization rules to cover cargo-new validation * refactor(embedded): Centralize placeholder This was originally split out because before #12269, it was needed elsewhere. * refactor(embedded): Be accurate in variable name * fix(toml)!: Prevent people parsing manifests from strings * test(embedded): Verify no autobin behavior is running * fix(embedded): Don't create an intermediate 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. This also exposes the fact that we didn't disable `autobins` like the documentation says we should. * fix(embedded): Ensure we don't auto-discover any targets * fix(cli): Make 'cargo foo.rs' behave like --manifest-path This mirrors the logic `ArgMatchesExt::root_manifest` * test(cli): Verify you can't use Cargo.toml * feat(cli): Accept 'cargo Cargo.toml' This wasn't in the original Pre-RFC but in terms of consistently accepting manifests everything, I think this makes sense. * refactor(core): Split out target-dir defaulting * fix(embedded): Keep target dir in cargo home 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 * feat: prepare for the next lockfile bump 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. * test(script): Verify existing build.rs behavior * 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. * 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. * test(embedded): Verify existing lockfile behavior * fix(embedded): Don't pollute script dir with lockfile 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. * fix: remove `-Zjobserver-per-rustc` again It was accidentally added back in rust-lang/cargo@cfffda9 * docs(cargo-test): missing apostrophe for possessive nouns * docs(cargo-test): clarify the cwd is for running tests * docs(unstable): remove tracking for `-Zdoctest-in-workspace` * test(embedded): Verify existing behavior on basic commands * docs(embedded): Cross-link impls * refactor: rename registry auth module to auth/mod.rs To be honest I don't even feel like they belong here. Maybe we should have a dedicated directory for registry-related code. * fix: Allow embedded manifests in all commands 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(cli): Unify manifest path error handling * fix(cli): Ensure we don't accidentally let embedded manifests on stable There should be a later check when parsing but just in case, let's have a check here as well. * refactor: extract asymmetric to its own module * refactor: rename registry module to registry/mod.rs * refactor: extract publish to its own module * refactor: extract search to its own module * refactor: extract login to its own module * refactor: extract logout to its own module * refactor: extract yank to its own module * refactor: extract owner to its own module * refactor: move http handle constructor to its own module * chore: update auto-label trigger files * Convert valid feature name warning to an error. * test(cli): Verify directory-manifest behaivor * test(cli): Verify missing-manifest behavior * fix(cli): Improve error on manifest dir * feat: check if `config-include` file ends with `.toml` 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. * test(config-include): assert config merged in DFS * doc(unstable): merge precedence of `-Zconfig-include` * docs(unstable): Point stable-unstable docs to nightly docs * build(deps): bump openssl from 0.10.54 to 0.10.55 Bumps [openssl](https://github.com/sfackler/rust-openssl) from 0.10.54 to 0.10.55. - [Release notes](https://github.com/sfackler/rust-openssl/releases) - [Commits](sfackler/rust-openssl@openssl-v0.10.54...openssl-v0.10.55) --- updated-dependencies: - dependency-name: openssl dependency-type: direct:production ... Signed-off-by: dependabot[bot] <[email protected]> * -Znext-lockfile-bump: Don't suggest using -Z on stable * test(script): Verify existing config behavior * fix(script): Process config relative to script, not CWD * cargo script example needs nightly -Zscript feature * refactor(cli): Decouple exec lookup from doing it * refactor(cli): Infer the command before configuring This will let the command have some sway in how we configure * test(script): Verify verbosity * fix(script): Be quiet on programmatic output The goal is that we shouldn't interefere with end-user output when "cargo script"s are used programmatically. The only way to detect this is when piping. CI will also look like this. My thought is that if someone does want to do `#!/usr/bin/env -S cargo -v`, it should have a consistent meaning between local development (`cargo run --manifest-path`) and "script mode" (`cargo`), so I effectively added a new verbosity level in these cases. To get normal output in all cases, add a `-v` like the tests do. Do `-vv` if you want the normal `-v` mode. If you want it always quiet, do `--quiet`. I want to see the default verbosity for interactive "script mode" a bit quieter to the point that all normal output cargo makes is cleared before running the built binary. I am holding off on that now as that could tie into bigger conversations / refactors (see https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/Re-thinking.20cargo's.20output). * docs(unstable): Update script documentation See #12207 for what all is merged thatt his is trying to cover. * refactor(toml): use macro to reduce boilerplates * refactor(toml): remove unnecessary clone on inheritable fields * refactor: move getters method together * doc: should be `.cargo-ok` * Add some more documentation for Source download functions. * Don't try to compile cargo-credential-gnome-secret on non-Linux platforms. * Add READMEs for the credential helpers. * docs(ref): Provide guidance on version requirements I've been dealing with these situations as either the package author, depending on such a package, or supporting users who run into problems that I figure documenting this guidance in a central place means I won't have to repeat myself as often and have to re-find all of the relevant links each time. Alternatives to how this was documented - Use a regular header. All of sections in this document are flat and its hard to see association between them. This also feels like its more on the level of the "note"s. - Put this in a central Recommendations page. I think we should do something more for these when we have more (nothing else in my quick scan stood out as "recommendations" like this). At that point we can have a better idea of how it would work (much like the rule of 3 for generalizing code). I also suspect a "Recommendations" index might be better. - Put this in the FAQ. This can easily be framed as a question and we put the `Cargo.lock` policy in there. I left out talking about alternative proc-macro designs as I feel like treading new ground in community practices is out of the scope of this. See also https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/Version.20Requirements.20documentation * doc: state `PackageId`/`SourceId` string is opaque Cargo tries to maintain the stability of every output it emits. However, for things like `PackageId` and `SourceId` users should see them as opaque strings. We generally don't change it but we want to reserve the right to change when it is required. * update re: multiple versions that differ only in the metadata tag Resolved by rust-lang/crates.io#1059 a few weeks ago * add another bin named "crabgo" with the same path changing the main bin name means modifying a lot of tests i don't see a reason to do that at this point * "cargo" -> "crabgo" * update readme * Squashed commit of the following: commit f86b54d Merge: 8505fe0 550ccf0 Author: Travis A. Wagner <[email protected]> Date: Fri Jun 23 13:53:42 2023 -0400 Merge pull request #6 from crablang/update-readme update readme commit 8505fe0 Merge: 5889303 e181e93 Author: Sammi Turner <[email protected]> Date: Fri Jun 23 12:07:50 2023 +0100 Merge pull request #5 from crablang/trav/rename rename commit 550ccf0 Author: Travis Wagner <[email protected]> Date: Fri Jun 23 05:36:15 2023 -0400 update readme commit e181e93 Author: Travis Wagner <[email protected]> Date: Fri Jun 23 05:03:22 2023 -0400 "cargo" -> "crabgo" commit 01ab24a Author: Travis Wagner <[email protected]> Date: Fri Jun 23 04:58:34 2023 -0400 add another bin named "crabgo" with the same path changing the main bin name means modifying a lot of tests i don't see a reason to do that at this point commit 5889303 Merge: c9b89c6 57326f5 Author: Travis A. Wagner <[email protected]> Date: Mon Jun 5 03:13:07 2023 -0400 Merge pull request #3 from crablang/synced synced * rm extra line --------- Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: Weihang Lo <[email protected]> Co-authored-by: Scott Schafer <[email protected]> Co-authored-by: MarcusGrass <[email protected]> Co-authored-by: bors <[email protected]> Co-authored-by: Sebastian Thiel <[email protected]> Co-authored-by: christian <[email protected]> Co-authored-by: Ed Page <[email protected]> Co-authored-by: c-git <[email protected]> Co-authored-by: Eric Huss <[email protected]> Co-authored-by: Artem Tokarev <[email protected]> Co-authored-by: Michael Diamond <[email protected]> Co-authored-by: Arpad Borsos <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Yerkebulan Tulibergenov <[email protected]> Co-authored-by: Adam Leventhal <[email protected]>
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.
No description provided.