profile
viewpoint

dtolnay/cargo-expand 676

Subcommand to show result of macro expansion

alexcrichton/toml-rs 663

A TOML encoding/decoding library for Rust

ehuss/cargo-prefetch 19

Cargo subcommand to download popular crates.

dqsully/atom-column-select 9

Atom package to enhance column selection.

ehuss/cargo-index 8

Cargo subcommand to manage a registry index.

ehuss/anno-2205-layouts 2

Tool for Anno 2205 layouts.

ehuss/atom-wrap-plus 2

Enhanced word wrapping for the Atom editor.

ehuss/cargo-clone-crate 1

Cargo subcommand to clone a repo from the registry.

ehuss/dotfiles 1

My dotfiles.

issue commentrust-lang/cargo

Cargo.lock updates automatically on `cargo build`

Ah, I see, sorry I misunderstood. I think this is a duplicate of #8468. This should be fixed on the latest nightly. I would use at least 2020-08-02.

de-sh

comment created time in an hour

push eventehuss/rust

Eric Huss

commit sha 3eff008754682c98d448e767c670dd44e3a4d32c

1mb cargo

view details

push time in an hour

push eventehuss/cargo

Eric Huss

commit sha 105e05596351de6807bc6ea7c919037d90c12508

Test 1MB

view details

push time in an hour

pull request commentrust-lang/cargo

Document build dependencies and dev dependencies

Hi! Thanks for the PR!

1. Should --deps document normal dependencies by default,

I think the default of "no" here makes sense to me.

2. Should --deps interact with --no-deps flag?

Hm, I would be inclined to just print an error if both flags are specified. They are somewhat contradictory. It's probably not too important either way.

A few questions and observations:

  • It's an interesting choice to never do transitive dependencies when using --deps. Do you think there might be a use case where someone would want transitive + normal + dev + build? (FWIW, there's a bunch of notes about transitive deps in #8296 with links to other issues.)
  • What do you think about adding an "all" option? I think the previous PR had something like that, and it seems like it would be a useful shortcut. My only concern is that it could be confusing regarding the "transitive" question above.
tmiasko

comment created time in an hour

Pull request review commentrust-lang/cargo

Document build dependencies and dev dependencies

 the `cargo help pkgid` command.  pub fn exec(config: &mut Config, args: &ArgMatches<'_>) -> CliResult {     let ws = args.workspace(config)?;-    let mode = CompileMode::Doc {-        deps: !args.is_present("no-deps"),-    };-    let mut compile_opts =-        args.compile_options(config, mode, Some(&ws), ProfileChecking::Checked)?;++    let mut deps_mode = DocDepsMode::default();+    if let Some(deps) = args.values_of("deps") {+        if !config.cli_unstable().unstable_options {+            Err(anyhow::anyhow!(+                "Usage of `--deps` requires `-Z unstable-options`"+            ))?;

There is a function for doing this:

config.cli_unstable().fail_if_stable_opt("--deps", 1234)?;

Can you open a tracking issue and use the issue number?

tmiasko

comment created time in an hour

push eventehuss/rust

Eric Huss

commit sha c7e71db31d91f20e79ba65fe4f56c37d76d26d5c

Test

view details

push time in 2 hours

PR opened rust-lang/rust

Cargo testing, ignore
+30 -25

0 comment

4 changed files

pr created time in 2 hours

push eventehuss/rust

Eric Huss

commit sha ad397570f955bee89067b3c3b122dbf3e1ad3c61

Test

view details

push time in 2 hours

create barnchehuss/rust

branch : close-output-xl

created branch time in 2 hours

issue commentrust-lang/cargo

Cargo.lock updates automatically on `cargo build`

Can you share a little more detail on a reproduction? If you are referring to a change like you mentioned at https://github.com/tikv/tikv/commit/b3f9c3325, then that is expected that when you change the URL, cargo will update the Cargo.lock for that dependency. If you need a specific git rev, you'll need to specify the rev field in the dependency.

de-sh

comment created time in 2 hours

issue commentrust-lang/cargo

Dependency linking to other than crates.io needed explicit update before noticing change of HEAD

If you change a dependency in Cargo.toml (such as the url), cargo build will automatically update the Cargo.lock entries for that dependency.

Nevsden

comment created time in 3 hours

create barnchehuss/cargo

branch : close-output-xl

created branch time in 3 hours

issue commentrust-lang/cargo

close_output test is randomly failing

With --test-threads 1 though you say you were able to reproduce, so where could the concurrent fork have happened?

That was when I had 0..1, which was probably related to the LineWriter behavior.

Cargo should try to print 10000 items from rustc, and surely that's enough to overflow PIPE_BUF. So even if the file descriptor is kept open surely at some point cargo blocks on the write, and then fails when the other associated processes exit?

Hm, good point. I did some tests, and I'm able to write 64KB to stdout or stderr before it starts blocking. I would have expected 4K. TIL, according to pipe(7), the buffer is 16 pages.

So, maybe the answer here is to just print more than 64KB of data?

ehuss

comment created time in 4 hours

issue commentrust-lang/cargo

close_output test is randomly failing

I'm returning to my original hypothesis that the issue is the file descriptor staying open because other threads are forking processes in the background, and there's a small window where the fd is duplicated. I'm able to repro with the following patch, running 1 test at a time (though it takes a while):

diff --git a/tests/testsuite/build.rs b/tests/testsuite/build.rs
index 01c16b515..1e00e3543 100644
--- a/tests/testsuite/build.rs
+++ b/tests/testsuite/build.rs
@@ -4939,6 +4939,14 @@ fn user_specific_cfgs_are_filtered_out() {
 fn close_output() {
     // What happens when stdout or stderr is closed during a build.

+    std::thread::spawn(|| {
+        let _test_guard = cargo_test_support::paths::init_root();
+        loop {
+            let _output = cargo_test_support::cargo_process("help")
+                .exec_with_output().unwrap();
+        }
+    });
+
     // Server to know when rustc has spawned.
     let listener = std::net::TcpListener::bind("127.0.0.1:0").unwrap();
     let addr = listener.local_addr().unwrap();
@@ -4975,7 +4983,7 @@ fn close_output() {
                     let mut buf = [0];
                     drop(socket.read_exact(&mut buf));
                     let use_stderr = std::env::var("__CARGO_REPRO_STDERR").is_ok();
-                    for i in 0..10000 {
+                    for i in 0..100 {
                         if use_stderr {
                             eprintln!("{}", i);
                         } else {

I'm not able to repro without other threads running in the background.

@alexcrichton I have two questions:

  • I kinda want to try to repro on rust-lang/rust's CI, do you think that would be worthwhile? I tried to repro on my account, but those only have 2 parallel jobs, and I wasn't able to.
    • As a side note, I noticed that the 4 failures were all with Intel(R) Xeon(R) CPU E5-2673 v4 @ 2.30GHz. The other hardware that is often used is Intel(R) Xeon(R) Platinum 8171M CPU @ 2.60GHz which is a much newer/beefier system. However, with only 4 data points, it might be just a coincidence.
  • Do you think it would be worthwhile to just move this test to a single-threaded test runner?
ehuss

comment created time in 6 hours

pull request commentrust-lang/cargo

clippy fixes, use matches! macro in more places

@bors r+

matthiaskrgr

comment created time in 18 hours

pull request commentrust-lang/rust

Update cargo

cc @alexcrichton ↑

Yea, it is difficult to get the defaults to accommodate all use cases. I would expect the negative effects to mostly happen for someone doing development with optimizations enabled. I'm curious how common that is. I suspect it is rare, but I've had a project where it was unusable without optimizations, so maybe not so rare.

FWIW, I did some benchmarking on a variety of real-world projects and a variety of parallel jobs, and the change was faster in every case for a from-scratch --release build.

If you want to restore the old behavior, you can set the env var CARGO_PROFILE_RELEASE_BUILD_OVERRIDE_OPT_LEVEL=3 (assuming the project doesn't override the default opt-level).

ehuss

comment created time in 18 hours

issue commentrust-lang/cargo

Regression: git ignored Cargo.lock prevents cargo publish

Perhaps follow up with the cbindgen project? Unfortunately cargo won't automatically include a Cargo.lock in the package unless there is a binary or example target. I'm guessing it runs cargo metadata which is generating a file within the package.

DoumanAsh

comment created time in 19 hours

issue commentrust-lang/cargo

Regression: git ignored Cargo.lock prevents cargo publish

@xnuter Source directory was modified by build.rs during cargo publish. That's a different message from this issue. Do you have a build script? It is not allowed to modify the package in any way.

DoumanAsh

comment created time in 20 hours

pull request commentrust-lang/cargo

Display embedded man pages for built-in commands.

OK, I have rebased after #8577, and I think this should be ready to go. I haven't done much testing on less-common platforms and terminals (just mac/windows/linux/freebsd with a variety of common terminals). I'm kinda hoping if people run into problems, they can file an issue.

ehuss

comment created time in a day

push eventehuss/cargo

Carlos Pérez

commit sha 7553724e80061d749c6fba7799020eff97c18e91

Merge pull request #1 from rust-lang/master Update fork

view details

Joshua Nelson

commit sha bb951880934c8f2eff77ce28673debff00ae7b6e

Don't overwrite existing `rustdoc` args with --document-private-items Instead, add that flag in addition to any existing flags.

view details

Joshua Nelson

commit sha 0a975e96d86810aa3986858febede53a90c369c0

Use a stable rustdoc option for testing

view details

Joshua Nelson

commit sha 1d1b3447813e4f39a6183a456de22ed3abe5ae87

Use entry API instead of a match This makes the code easier to read and also avoids looking up the position in the map twice. The clone of `unit` is very cheap since it is an Rc.

view details

Eric Huss

commit sha dec7872acf364214b4413ba603f209ae8fb0957b

Update metadata man page.

view details

Martin Pool

commit sha e9dba420c3813da7c8b68ba58ed75b6f9344b2de

Write GNU tar files, supporting long names. Fixes #8452

view details

Martin Pool

commit sha 0dfd4a88fd88aba6aa27a9f7c552a23f414b6f70

Add test for packaging long file names

view details

Gabriel Majeri

commit sha 4c7be8d4fb0a1fa22eb2bf1bbef8dc3be4363c8d

Add a test reproducing the issue

view details

bors

commit sha f236c35e56630ee131dede70433447ad2f4fa606

Auto merge of #8451 - ehuss:metadata-man, r=Eh2406 Update metadata man page. The man pages needed to be rebuilt after #8323.

view details

Eric Huss

commit sha 337fd9f0157941d8e75b5199ac094ec8f2bfaa30

Add some help about rustup's +toolchain syntax.

view details

bors

commit sha 299514d09252081f0b740e7c490e87fec97f4386

Auto merge of #8455 - ehuss:rustup-toolchain, r=Eh2406 Add some help about rustup's +toolchain syntax. This tries to bring more attention to the `+toolchain` syntax from rustup. Closes #8058

view details

bors

commit sha c95c0b1c53364c4f43b36cfbcb062f06ea01a5bf

Auto merge of #8449 - jyn514:rustdoc, r=ehuss Don't overwrite existing `rustdoc` args with --document-private-items Instead, add that flag in addition to any existing flags. Closes https://github.com/rust-lang/cargo/issues/8445

view details

bors

commit sha 548eea773fda4d73209d0833cd7655c97b8f0014

Auto merge of #8453 - sourcefrog:name-length-limit-8452, r=alexcrichton Write GNU tar files, supporting long names. Fixes #8452 If I understand the previous bugs correctly, long trees packaged using Cargo with this patch will be misinterpreted by Cargo from before Jan 2016. (Without this patch, they can't be written at all.) To me that seems like long enough ago that it's safe to land this now. - [x] Add a test.

view details

Gabriel Majeri

commit sha 65fc4cec8d6d5952f8433c0d16e02a5855a9aaaf

Implement enum config options deserialization

view details

bors

commit sha 729e5676a02404b1d745013f8b280945cfa2d50d

Auto merge of #8454 - GabrielMajeri:config-option-enum, r=ehuss Add support for deserializing enums in config files Implements `deserialize_enum` functionality to allow config options which are Rust enums. @ehuss The code currently has some `todo!`s because I'm not sure how the custom `Deserializer` is supposed to do error handling. Fixes #8450

view details

Alex Berghage

commit sha 1cea4cbe854a0cedb69e42058977c35a9b762bca

Allow populating CliUnstable from a HashMap This makes it easier to populate unstable options from configuration files. Might also help make unstable option tests easier to write.

view details

Alex Berghage

commit sha 4aede8c7847748c3b46afa176436387cf8f0593a

Allow setting unstable options in .cargo/config Obviously this only works with nightlies and all that, but if you're e.g. testing resolver v2, want to always have Ztiming on in your workspace, or something like that, this makes it easier to do.

view details

Alex Berghage

commit sha 9cb1ef88b6a7241773ebec42fdd959b065b10368

Allow both dashes and underscores for Z flags This makes it a little easier to match whatever the natural formatting is for where you're setting unstable options -- CLI or config file.

view details

Alex Berghage

commit sha c60da96b511ea48cacdbe6611b40698db7feb6f8

Update src/doc/src/reference/unstable.md Co-authored-by: Eric Huss <eric@huss.org>

view details

Alex Berghage

commit sha 6d7421cacb545496d57cfcd4b9eea89ed81ab03e

Clarify CliUnstable::parse/update_with_table These masquerade like construction functions, but they're in-place mutators since they're meant to be used one after another in a precedence chain.

view details

push time in a day

issue commentrust-lang/rust

Add a macro to track a file

cc #74690, where the ability to register the usage of an environment variable was added. I would suspect adding support for tracking files could use a similar mechanism. I'm not sure if this specifically needs to use a macro, or if a function call would be sufficient (tracked_env::file(...)? tracked_env::path(...)?).

GuillaumeGomez

comment created time in a day

pull request commentrust-lang/cargo

Add mdman for generating man pages.

Thanks for taking a look! And sorry it's such a big diff. I did split it up into multiple commits to try to organize things a little. If any issues come up, I'll try to take care of them. I don't have anything else here, so: @bors r=alexcrichton

ehuss

comment created time in a day

Pull request review commentrust-lang/cargo

clippy fixes, use matches! macro in more places

 fn long_file_names() {         test_path.mkdir_p();         let test_path = test_path.join(long_name);         if let Err(e) = File::create(&test_path) {-            use std::io::Write;-            writeln!(-                std::io::stderr(),+            eprintln!(                 "\nSkipping long_file_names test, this OS or filesystem does not \                 appear to support long file paths: {:?}\n{:?}",-                e,-                test_path-            )-            .unwrap();+                e, test_path+            );

This was specifically written to write to stderr to avoid libtest from capturing the output (so that it is always displayed, even without --nocapture). Can you change it back? (And maybe add a comment explaining that, since it isn't obvious.)

matthiaskrgr

comment created time in a day

pull request commentrust-lang/cargo

cargo install with specific yanked version gives confusing "not found" error

Can you please have a look at the CI/test the failed one. I'm unable to get details like why 2 tests are failing. Thanks

This was just something that changed in nightly, it should be fixed now (via #8576). If you rebase on the latest master, it should be fixed.

pawanbisht62

comment created time in a day

Pull request review commentrust-lang/cargo

cargo install with specific yanked version gives confusing "not found" error

 where             let pkg = Box::new(source).download_now(pkgid, config)?;             Ok(pkg)         }-        None => bail!(-            "could not find `{}` in {} with version `{}`",-            dep.package_name(),-            source.source_id(),-            dep.version_req(),-        ),+        None => {+            let version: String = dep.version_req().to_string();+            match PackageId::new(dep.package_name(), &version[1..], source.source_id()) {+                Ok(pkg_id) => {+                    if source.is_yanked(pkg_id).unwrap_or(false) {+                        bail!(+                            "cannot install package `{}`, it has been yanked from {}",+                            pkg_id.name(),+                            pkg_id.source_id()+                        )+                    } else {+                        bail!(+                            "could not find `{}` in {} with version `{}`",+                            dep.package_name(),+                            source.source_id(),+                            dep.version_req(),+                        )+                    }+                }+                Err(_) => bail!(+                    "could not find `{}` in {} with version `{}`",

Can this be restructured to avoid the duplication of these two cases? Maybe something like:

let maybe_pkg_id = PackageId::new(dep.package_name(), &version[1..], source.source_id());
let is_yanked = maybe_pkg_id.map_or(false, |pkg_id| source.is_yanked(pkg_id).unwrap_or(false));
if is_yanked {
    // ...yanked error
} else {
    // ...not found error
}
pawanbisht62

comment created time in a day

Pull request review commentrust-lang/cargo

cargo install with specific yanked version gives confusing "not found" error

 fn install_git_with_symlink_home() {         )         .run(); }++#[cargo_test]+fn install_yanked_cargo_package() {+    Package::new("baz", "0.0.1").yanked(true).publish();+    cargo_process("install baz --version 0.0.1")+        .with_status(101)+        .with_stderr_contains("error: cannot install package `baz`, it has been yanked from registry `https://github.com/rust-lang/crates.io-index`")

Can you split up this line so it is less than 100 characters long? Just add some \ characters to split the string across a few lines.

pawanbisht62

comment created time in a day

Pull request review commentrust-lang/cargo

cargo install with specific yanked version gives confusing "not found" error

 where             let pkg = Box::new(source).download_now(pkgid, config)?;             Ok(pkg)         }-        None => bail!(-            "could not find `{}` in {} with version `{}`",-            dep.package_name(),-            source.source_id(),-            dep.version_req(),-        ),+        None => {+            let version: String = dep.version_req().to_string();+            match PackageId::new(dep.package_name(), &version[1..], source.source_id()) {

I'm a little uncomfortable just blindly stripping the first character from the version req. Perhaps only do the check if version_req().is_exact()? I think that should guarantee that it is = followed by an exact version.

Which reminds me that this doesn't help for non-specific versions (like * or ~2). That's probably a bigger can of worms, though.

pawanbisht62

comment created time in a day

Pull request review commentrust-lang/cargo

cargo install with specific yanked version gives confusing "not found" error

 fn already_installed_updates_yank_status_on_upgrade() {      cargo_process("install foo --version=1.0.1")         .with_status(101)-        .with_stderr(-            "\-[UPDATING] `[..]` index-[ERROR] could not find `foo` in registry `[..]` with version `=1.0.1`-",+        .with_stderr_contains(+            "error: cannot install package `foo`, it has been yanked from registry `https://github.com/rust-lang/crates.io-index`",

This string could be split up, too.

pawanbisht62

comment created time in a day

pull request commentrust-lang/cargo

Add an option to force show progress bar on notty

Maybe I'm a bit confused, but all config options can be set with environment variables. In this case, it would be CARGO_TERM_PROGRESS_WIDTH=100, which should override any user settings.

mchernyavsky

comment created time in a day

issue commentrust-lang/cargo

Rebuild/emit new object file if it has been removed but the source has not changed

However, I wonder why the --target flag is necessary.

I think it's probably just an oversight. It seems reasonable to me for cargo clean to use build.target by default.

micouy

comment created time in a day

issue commentalexcrichton/toml-rs

Serialization error

As described in the ValueAfterTable error, it is not possible to have values after tables, you'll need to rearrange it so that the tables are at the end of the definition. There currently isn't a way to control the use of inline tables (#265).

0xdeafbeef

comment created time in a day

Pull request review commentrust-lang/reference

Some constant/static updates.

 Notable features that const contexts have, but const fn haven't are: * union field access * [`transmute`] invocations. +Conversely, the following are possible in a const function, but not in a const context:++* Use of generic parameters.

Hm, maybe I'm a bit confused. The following seems to work for me:

const fn cfunc<T>(x: &T) -> usize {
    std::mem::size_of::<T>()
}
ehuss

comment created time in a day

Pull request review commentrust-lang/reference

Some constant/static updates.

 to be run. A _const context_ is one of the following:  * [Array type length expressions]-* Repeat expression length expressions+* [Array repeat expressions][array expressions]

Oops, sorry! I probably shouldn't open PRs late at night.

ehuss

comment created time in a day

push eventehuss/reference

Eric Huss

commit sha da910b725a59ba9bb32c6954074f377589a2a689

Update from review comments.

view details

push time in a day

push eventrust-lang/reference

ximon18

commit sha acc8f542992214297bcfb7d1fd6e8ddabbb82cac

Update README.md The `mdbook build` default output directory is `book`, not `docs`.

view details

Eric Huss

commit sha c9b2736a059469043177e1e4ed41a55d7c63ac28

Merge pull request #870 from ximon18/patch-1 Fix documented build output path.

view details

push time in a day

PR merged rust-lang/reference

Fix documented build output path.

The mdbook build default output directory is book, not docs.

+1 -1

0 comment

1 changed file

ximon18

pr closed time in a day

issue commentrust-lang/cargo

close_output test is randomly failing

Hm, sorry for the misleading direction. I wasn't aware of that interaction with LineWriter. However, I'm quite easily able to reproduce with 0..10. I ran tests for several hours today with 0..10000, but I wasn't able to repro. I thought I had done that in the past, but my memory is foggy.

My original intent with the 10,000 was just to ensure there wasn't any silliness with PIPE_BUF, but it wasn't based on any evidence.

I'll continue poking on this.

ehuss

comment created time in 2 days

Pull request review commentrust-lang/reference

Clarify rules about immutable statics

 A *static item* is similar to a [constant], except that it represents a precise memory location in the program. All references to the static refer to the same memory location. Static items have the `static` lifetime, which outlives all-other lifetimes in a Rust program. Non-`mut` static items that contain a type-that is not [interior mutable] may be placed in read-only memory. Static items-do not call [`drop`] at the end of the program.+other lifetimes in a Rust program. Static items do not call [`drop`] at the end+of the program. Note that [external statics] have additional restrictions. -All access to a static is safe, but there are a number of restrictions on-statics:+## Non-`mut` statics++Non-`mut` static items that contain a type+that is not [interior mutable] may be placed in read-only memory. ++All access to a non-`mut` static is safe, but there are a number of restrictions:

The rules below here seem to apply to both mut and non-mut static, right?

Note that I removed the second item in #867, as it is out-of-date.

Coder-256

comment created time in 2 days

issue openedrust-lang/reference

document negative impls

Unless I'm blind, I cannot find any discussion of negative impls. It is in the grammar, and mentioned briefly in the special types page. I think there should be a section in the implementations page.

created time in 2 days

PR opened rust-lang/reference

Update token usage table.

Some usages that I missed previously.

+13 -5

0 comment

1 changed file

pr created time in 2 days

pull request commentrust-lang/reference

Some constant/static updates.

@oli-obk Do you think you'd be able to review this?

ehuss

comment created time in 2 days

PR opened rust-lang/reference

Some constant/static updates.
  • Clarify that array length is a "constant expression". Closes #582.
  • Remove restriction that statics must use other statics by reference. This was removed in https://github.com/rust-lang/rust/pull/51110 (1.29 I believe).
  • Clarify that paths to statics are allowed only within static initializers.
  • Add a clarification of usage of constants from external crates (closes #22 I believe).
  • Mention that generic parameters cannot be used in a const context (https://github.com/rust-lang/rust/issues/43408)
  • Some other minor tweaks.
+21 -12

0 comment

4 changed files

pr created time in 2 days

create barnchehuss/reference

branch : update-token-links

created branch time in 2 days

push eventehuss/reference

Eric Huss

commit sha 2f459e22ec30a94bafafe417da4e95044578df73

Some constant/static updates.

view details

push time in 2 days

create barnchehuss/reference

branch : const-updates

created branch time in 2 days

issue closedrust-lang/reference

Document extern statics

These currently are undocumented. As well as some documentation on the extern blocks page, accessing an extern static needs to be added to unsafety.md

closed time in 2 days

matthewjasper

issue commentrust-lang/reference

Document extern statics

I'm going to close this, since it seems to be mostly addressed (or at least, the basics are in place). The unsafety note was added in #459 and the start of extern static docs was added in #736.

If I misunderstood the issue, feel free to reopen, or open new issues with more specific notes about things that are missing or incorrect.

matthewjasper

comment created time in 2 days

issue closedrust-lang/cargo

"cargo fix --edition" claims no failure, but crate can not be built with edition = "2018"

<!-- Thanks for filing a 🐛 bug report 😄! -->

Problem I want to migrate the containers crate to the 2018 edition. I do "cargo fix --edition" in the crate root, which emits no error message, then write 'edition = "2018"' in Cargo.toml, but building the crate so fails.

Wanted outcome: Crate can be built with edition = "2018". Actual outcome: "cargo build" fails.

Steps <!-- The steps to reproduce the bug. -->

  1. git clone https://github.com/strake/containers.rs
  2. git checkout a0a3e5df95057a015e6935a13f3a4b893329f39e
  3. cargo fix --edition
  4. <write 'edition = "2018"' in Cargo.toml>
  5. cargo build

Possible Solution(s) <!-- Not obligatory, but suggest a fix/reason for the bug, --> <!-- or ideas how to implement the addition or change -->

Notes

Seems to be due to name conflicts between the ptr crate and core::ptr. I am not sure how to bestly disambiguate, but "cargo fix" should at least emit an error message and fail.

Output of cargo version: cargo 1.45.0 (744bd1fbb 2020-06-15)

<!-- Also, any additional context or information you feel may be relevant to the issue. --> <!-- (e.g rust version, OS platform/distribution/version, target toolchain(s), release channel.. -->

closed time in 2 days

strake

issue commentrust-lang/cargo

"cargo fix --edition" claims no failure, but crate can not be built with edition = "2018"

Thanks for the report! This is a known issue, tracked in https://github.com/rust-lang/rust/issues/53797. For now you'll need to manually fix any remaining errors.

strake

comment created time in 2 days

issue commentrust-lang/rust

Rustc does not warn about `use` with paths incompatible with `uniform_paths` for edition 2018

Another example, encountered by a user:

#![deny(rust_2018_compatibility)]
extern crate ptr;

pub mod foo {
    pub use std::ptr;
    pub use ptr::Shared;
}

Does not generate any errors/warnings, but fails to compile on 2018.

orium

comment created time in 2 days

push eventehuss/cargo

Eric Huss

commit sha 7810a2fab523a877ca5b9c535b0111b7f4e26b03

with cpu

view details

push time in 2 days

create barnchehuss/cargo

branch : ci-close-output

created branch time in 2 days

PR opened rust-lang/cargo

Fix broken link in Build Cache chapter.
+1 -0

0 comment

1 changed file

pr created time in 3 days

create barnchehuss/cargo

branch : fix-build-cache-link

created branch time in 3 days

push eventehuss/cargo

Eric Huss

commit sha 566706e8632b7a3c3e93701283e3125df3c9f447

Fix some Windows newline behavior.

view details

push time in 3 days

PR opened rust-lang/cargo

Add mdman for generating man pages.

This introduces a new utility called mdman that converts a markdown-formatted document to a man page. This replaces asciidoctor, with the intent to make it easier to contribute, easier to have consistent formatting across platforms, and easier to generate plain-text documents for use on Windows (for #8456). This also includes a number of formatting fixes.

There is some documentation in the mdman/doc directory explaining how to use it, and the docs in src/doc/README.md have been updated (this explains the structure of the files). The Makefile has been replaced with a simple shell script.

CI has been updated to verify the checked-in docs are up-to-date. Perhaps in the future, these can be generated automatically (perhaps by build.rs?), but since that requires a bit of build system work (like upstream rust), this is deferred till later.

+23860 -19914

0 comment

282 changed files

pr created time in 3 days

push eventehuss/cargo

Eric Huss

commit sha 8b878f38cda7bc771568162cac344fe8aa9003b2

Add mdman for generating man pages.

view details

Eric Huss

commit sha 5594bfa4bde59eaedfdff6c1e77ee215f978e0e2

Move asciidoc man pages to markdown.

view details

Eric Huss

commit sha 7b7d80e84ae74dd620c0f294d6f12ada16cdb94e

Reformat asciidoc man pages to markdown.

view details

Eric Huss

commit sha 25291c6c3644d3ac3744ca6fc239469a2bc99300

Remove old HTML generated man pages.

view details

Eric Huss

commit sha 2d4aa38b4f79e8e50048aba9e97d9e6cf63c5e9f

Regenerate man pages using mdman.

view details

Eric Huss

commit sha 3134eef059dfbeb689317e2e7064fa3bdf8bfd48

Docs, CI, and tools for building man pages.

view details

push time in 3 days

create barnchehuss/cargo

branch : mdman-vtest

created branch time in 3 days

push eventehuss/cargo

Eric Huss

commit sha 226d2e23f9e9a70e60668376d028aafe543cc648

Add mdman for generating man pages.

view details

Eric Huss

commit sha a59935d0600c07cc58b1cdaa80636718aa1fce0c

Move asciidoc man pages to markdown.

view details

Eric Huss

commit sha 121f341f29763753a58fc9b50fd620bbcb585f4c

Reformat asciidoc man pages to markdown.

view details

Eric Huss

commit sha d61ef39b52e49b63773ca8989cf0eadddcb98a27

Remove old HTML generated man pages.

view details

Eric Huss

commit sha aeddd53514d7a1c5471affcfca6c9d80bde3100d

Regenerate man pages using mdman.

view details

Eric Huss

commit sha 9d9731f7c5cd7eb1375864dde69d57ff4855790a

Docs, CI, and tools for building man pages.

view details

push time in 3 days

pull request commentrust-lang/cargo

clippy fixes, use matches! macro in more places

Hm, I can't reproduce any test failure locally. :/

Posted a fix at #8576.

matthiaskrgr

comment created time in 3 days

PR opened rust-lang/cargo

Fix intra-doc tests for renamed lint.

The lint was renamed in https://github.com/rust-lang/rust/pull/74926.

+1 -1

0 comment

1 changed file

pr created time in 3 days

create barnchehuss/cargo

branch : fix-broken_intra_doc_links

created branch time in 3 days

push eventehuss/cargo

Eric Huss

commit sha 81d4179610527dd740e8d74d34e6ad33874109a0

Docs, CI, and tools for building man pages.

view details

push time in 3 days

create barnchehuss/cargo

branch : mdman

created branch time in 3 days

pull request commentrust-lang/rust

submodules: update cargo from 974eb438d to 2d5c2381e

@bors p=1 Fixing nightly regression.

matthiaskrgr

comment created time in 3 days

pull request commentrust-lang/rust

submodules: update cargo from 974eb438d to 2d5c2381e

@bors r+

matthiaskrgr

comment created time in 4 days

issue commentlibgit2/libgit2

Repository fetch failure, only on i686

In my investigation, the issue seems to be this line. At position 33554391 in the index file the window hash shrunk to 41 bytes, which is quite small. It ends up returning Z_BUF_ERROR, even though it successfully inflated the 35 bytes it needs. I don't fully understand the interaction between the zstream and the mwindow, but something like this fixes the problem (which is obviously a hack):

diff --git a/src/pack.c b/src/pack.c
index 4294a6e32..3a8667588 100644
--- a/src/pack.c
+++ b/src/pack.c
@@ -858,7 +858,7 @@ static int packfile_unpack_compressed(
                total += bytes;
        } while (total < size);

-       if (total != size || !git_zstream_eos(&zstream)) {
+       if (total != size || (zstream.zerr != Z_STREAM_END && zstream.zerr != Z_BUF_ERROR) ) {
                git_error_set(GIT_ERROR_ZLIB, "error inflating zlib stream");
                error = -1;
                goto out;

The reason the window has shrunk so small is that on a 32-bit build, the maximum mwindow size is 32MB which is smaller than this large pack file. In a 64-bit build, it is able to map the entire thing, so the window doesn't need to move around.

So I don't think this is a 32-bit bug exactly. This could in theory be encountered in 64-bit with a pack file over 1GB.

In general, I don't see any handling of Z_BUF_ERROR, which is a non-fatal error. There might be other situations where it needs to be handled.

Also, as a side note, I think this line should check for a NULL return.

alexcrichton

comment created time in 4 days

pull request commentrust-lang/cargo

Use the same index location on nightly as beta

Thanks! @bors r+

alexcrichton

comment created time in 4 days

issue closedrust-lang/reference

proc_macro_attribute dependency

Let's assume you have two user defined proc_macro_attributes in the following order:

struct Test {}

#[depends_on_inner]
impl Test {

    #[inner]
    fn test() {

    }
}

Is there any way to hand over information between these two macro executions, so that depends_on_inner knows that impl Test has a function with a #[inner] attribute?

closed time in 4 days

exellian

issue commentrust-lang/reference

proc_macro_attribute dependency

I'm uncertain if there's a common way to relay information. depends_on_inner can parse its input and notice the presence of the inner attribute, but I'm uncertain if that's guaranteed (see #692 and its linked issues).

Questions like these should be asked on one of the user forums, like https://users.rust-lang.org/.

exellian

comment created time in 4 days

push eventrust-lang/reference

Aleksey Kladov

commit sha d5cc65a70f66a243d84cd251188d80fbe9926747

Allow trait inner attributes

view details

Eric Huss

commit sha 0c4059d9729c1908b421dbcb98a2df5a3d3afffc

Merge pull request #864 from matklad/traitinneritems Allow trait inner attributes

view details

push time in 4 days

PR merged rust-lang/reference

Allow trait inner attributes

r? @ehuss

+2 -0

1 comment

1 changed file

matklad

pr closed time in 4 days

issue closedrust-lang/cargo

Are multiple binaries fully supported?

I have a cargo project like this: image

I know that bin-a/main.rs can access mod1's pub struct through mod mod1, but how does mod1 access mod2's pub struct?

closed time in 4 days

hongliang5316

issue commentrust-lang/cargo

Are multiple binaries fully supported?

bin-a/main.rs should have:

mod mod1;
mod mod2;

and inside mod1.rs to access something from mod2 you can reference it via the path crate::mod2::my_struct.

Questions like these should be asked on one of the user forums (like https://users.rust-lang.org/).

hongliang5316

comment created time in 4 days

issue commentrust-lang/cargo

Testing a proc macro may build with the wrong crates with -Zfeatures=all

This is a tricky one, somewhat the confluence of three different issues. The following is mostly notes to myself.

The primary issue is probably #8549. the-macro-support needs to be built twice (once for host, once without), but due to unit unification (without --target), it is only built once because the only difference is what it links to (shared with no features, and shared with feature B).

Another issue is this line. This forces proc-macros to be built for-host, even if it is a test. So the fix to above doesn't completely solve the issue.

Another issue is possibly #8312. proc-macros have some unusual requirements (like this). Not sure how this fits in the picture. There is some wonkiness around cargo test for proc-macros.

alexcrichton

comment created time in 4 days

push eventrust-lang/reference

Pand9

commit sha 7ab184c0ec27485ec734900946d9b2e1e2a91428

patterns.md - add word "underscore" to _ paragraph Add word "underscore" for better search accessibility. `_` is a short, widely-used symbol and I didn't even try to search for it. I think this simple change can prevent someone (would have prevented me) from being confused & asking on Reddit :)

view details

Eric Huss

commit sha d4f5bab83da0ad969d6792854b4e3c1b596dcf42

Merge pull request #865 from Pand9/patch-1 patterns.md - add word "underscore" to _ paragraph

view details

push time in 4 days

PR merged rust-lang/reference

patterns.md - add word "underscore" to _ paragraph

Add word "underscore" for better search accessibility. _ is a short, widely-used symbol and I didn't even try to search for it. I think this simple change can prevent someone (would have prevented me) from being confused & asking on Reddit :)

+1 -1

0 comment

1 changed file

Pand9

pr closed time in 4 days

pull request commentrust-lang/cargo

cargo install with specific yanked version gives confusing "not found" error

For Cargo's testsuite, there is some high-level documentation in https://github.com/rust-lang/cargo/blob/master/CONTRIBUTING.md#running-tests for running tests. See https://github.com/rust-lang/cargo/blob/master/crates/cargo-test-support/src/lib.rs for an introduction to writing tests.

The test should probably go in https://github.com/rust-lang/cargo/blob/master/tests/testsuite/install.rs. There are a bunch of other tests in there that you can look at for examples. The simple test up top is a good, basic example.

Essentially it needs to call Package::new to create a new package in the registry, and call yanked to set its yanked status.

Then call cargo_process("install foo") and check that it fails with_status(101) and that check the output using with_stderr("...").

pawanbisht62

comment created time in 4 days

issue commentrust-lang/cargo

cargo clippy is no-op when edition = 2018

You will need to follow up with the clippy team (either in one of the linked issues above, or file a new issue on their repo, or ask on Discord).

As for CARGO_LOG, it is mostly undocumented, as it is normally only used for debugging. It is mentioned here for contributors. It tends to be very low-level, and not easily usable by end-users.

Pand9

comment created time in 4 days

issue commentrust-lang/rust

"x.py doc" fails

Fixing this properly looks like it will be quite tricky. Some of the complexity stems from the fact that the rustc wrapper does not set the sysroot without a --target flag, which is what happens when running cargo doc (see here). However, the rustdoc wrapper always sets the sysroot here. This means that dependencies that are built with rustc (for .rmeta) use the beta sysroot (stage0), and rustdoc is using the stage0-sysroot folder with the newly built std.

As an aside, if this is fixed to support stage0, this line will probably need to be changed to Std, not Rustc. There's no need to build Rustc to document itself.

tshepang

comment created time in 4 days

issue commentrust-lang/cargo

cargo clippy is no-op when edition = 2018

I believe you are seeing that clippy shares the cache with cargo check. If you run cargo check, then it won't run clippy because it believes it has already completed. You can run cargo +nightly clippy -Zunstable-options to avoid the caching. There are more details at #8143 and https://github.com/rust-lang/rust-clippy/issues/4612 and https://github.com/rust-lang/rust-clippy/issues/3837.

As for logging, the CARGO_LOG environment variable can be used to provide debugging information about cargo's behavior. For example CARGO_LOG=cargo::core::compiler::fingerprint=trace will display information about cargo's fingerprinting.

Pand9

comment created time in 4 days

Pull request review commentrust-lang/cargo

cargo install with specific yanked version gives confusing "not found" error

 where             let pkg = Box::new(source).download_now(pkgid, config)?;             Ok(pkg)         }-        None => bail!(-            "could not find `{}` in {} with version `{}`",-            dep.package_name(),-            source.source_id(),-            dep.version_req(),-        ),+        None => {+            for pkg_id in deps.iter() {+                if source.is_yanked(pkg_id.package_id()).unwrap_or(false) {+                    bail!("provided package has been yanked `{}`", pkg_id.package_id())

Just a small note on the wording, perhaps it could be written as:

cannot install package `{}`, it has been yanked from {}

pawanbisht62

comment created time in 4 days

issue openedrust-lang/cargo

index hash has changed

As a result of #8522 changing the hash computation, the crates.io index path has changed from the long-running github.com-1ecc6299db9ec823 to github.com-f1e60147b9cdaa30. My main concern here is the increase in disk usage, since these tend to be kinda weighty (the new one is 81MB, my old one had accumulated 230MB).

I'm wondering if it would be better to try to match the old hash for this circumstance? Since Cargo doesn't have any sort of built-in garbage collection, the old index will persist unless the user manually deletes it.

created time in 4 days

push eventrust-lang/mdBook

Érico Rolim

commit sha 78aa2a16f84ea32c15b311086e517a08fd6dab9d

Mention that uninstalled backend isn't marked optional. If an uninstalled backend (command not found) isn't marked optional, warn about it, since it causes mdbook commands to error out. Fixes #1283

view details

Eric Huss

commit sha 8746206060960dc9e0e6c1d122976af64883fe43

Merge pull request #1284 from ericonr/opt Mention that uninstalled backend isn't marked optional.

view details

push time in 5 days

PR merged rust-lang/mdBook

Mention that uninstalled backend isn't marked optional.

If an uninstalled backend (command not found) isn't marked optional, warn about it, since it causes mdbook commands to error out.

Fixes #1283

+6 -2

0 comment

2 changed files

ericonr

pr closed time in 5 days

issue closedrust-lang/mdBook

What is the intended behavior when a backend isn't available?

Hi there! We are using mdbook for the Void Linux handbook. We have configured the mdbook-linkcheck backend to help with verifying contributions, since it keeps any dead links out of the handbook. However, when deploying the book, we don't include have mdbook-linkcheck available in the machine, and it simply complains about not finding the plugin, but still builds the whole book perfectly.

However, when using mdbook serve and mdbook-linkcheck isn't available, it errors out completely, with the error message below:

2020-07-24 00:42:26 [INFO] (mdbook::book): Book building has started
2020-07-24 00:42:26 [INFO] (mdbook::book): Running the html backend
2020-07-24 00:42:26 [INFO] (mdbook::book): Running the linkcheck backend
2020-07-24 00:42:26 [INFO] (mdbook::renderer): Invoking the "linkcheck" renderer
2020-07-24 00:42:26 [ERROR] (mdbook::renderer): The command `mdbook-linkcheck` wasn't found, is the `linkcheck` backend installed?
2020-07-24 00:42:26 [ERROR] (mdbook::utils): Error: Rendering failed
2020-07-24 00:42:26 [ERROR] (mdbook::utils): 	Caused By: Unable to start the backend
2020-07-24 00:42:26 [ERROR] (mdbook::utils): 	Caused By: No such file or directory (os error 2)

Ideally, I would like to be able to serve the handbook locally for testing purposes without having mdbook-linkcheck installed. I can try to fix this issue, but I don't know what the preferred behavior is. Would it be desirable to remove the failure from mdbook serve, so it acts like mdbook build and simply complains about the lacking backend, or should mdbook serve accept a flag to ignore missing backends and/or not use any backends beyond the HTML one?

closed time in 5 days

ericonr

pull request commentrust-lang/reference

Allow trait inner attributes

Thanks! This is a tiny part of #751 (from https://github.com/rust-lang/rust/pull/68728). I believe there are much larger changes to the grammar needed here, but this seems good on its own.

The link is broken, though. Would you mind adding [_InnerAttribute_]: ../attributes.md to the bottom of the file?

matklad

comment created time in 5 days

push eventrust-lang/mdBook

Érico Rolim

commit sha dcf9462d1e69975d505dfb1b6d4139acb89f10a1

summary: turn SoftBreak events into spaces. Summary items that had their name split into two lines ended up with the last word of one line and the first word of the next line glued together, since a space wasn't added. Added test case for it. Fixes #1218

view details

Eric Huss

commit sha f5ae7c4f1379ebcfb40f29dc9e291fff9ff11c5c

Merge pull request #1291 from ericonr/fix-break summary: turn SoftBreak events into spaces.

view details

push time in 5 days

PR merged rust-lang/mdBook

summary: turn SoftBreak events into spaces.

Summary items that had their name split into two lines ended up with the last word of one line and the first word of the next line glued together, since a space wasn't added.

Fixes #1218

+21 -0

3 comments

1 changed file

ericonr

pr closed time in 5 days

issue closedrust-lang/mdBook

Sidebar doesn't add a space character when item is split in two lines

Hey there! We are using mdBook for the documentation for Void Linux, here: https://docs.voidlinux.org/.

If you look at the sidebar, under graphics drivers, there's a "NVIDIAOptimus" item. This item is specified in SUMMARY.md as:

- [NVIDIA
   Optimus](link.)

It is split in two lines due to our linting, where lines are constrained to 80 columns. The original source can be found in https://raw.githubusercontent.com/void-linux/void-docs/master/src/SUMMARY.md . GitHub formatting, when displaying this file (here), displays it correctly as "NVIDIA Optimus".

This seems to be a bug when creating the sidebar. I haven't noticed anything similar with normal files.

Thanks!

closed time in 5 days

ericonr

pull request commentrust-lang/cargo

Don't print to raw stderr in test

:see_no_evil: @bors r+

alexcrichton

comment created time in 5 days

issue closedrust-lang/rust

No console colors on Windows 7

I just updated Rust at work, and now rustc has no colors in the console (Cargo still does). I'm using Windows 7 64-bit with Rust MSVC 32-bit. I tried 1.29 stable and it worked, but 1.30 stable and the latest nightly don't work. I have tried both cmd.exe and PowerShell and both look the same. This is a big regression in usability, so I'll probably downgrade back to a working version.

rustc_no_colors

closed time in 5 days

jminer

issue commentrust-lang/rust

No console colors on Windows 7

This should be fixed on the latest nightly (2020-07-31) via https://github.com/rust-lang/cargo/pull/8540 and https://github.com/rust-lang/rust/pull/74923.

jminer

comment created time in 5 days

issue closedrust-lang/cargo

Colors from rustc are not shown on Windows.

Environment is Windows 7 with cmd.exe. Rust and cargo are stable 1.42, nightly does the same.

Here’s a screenshot: Screenshot

struct S;
fn main() {
    let x = S;
    drop(x);
    drop(x);
}

closed time in 5 days

steffahn

issue commentrust-lang/cargo

Colors from rustc are not shown on Windows.

This should be fixed on the latest nightly (2020-07-31) via https://github.com/rust-lang/cargo/pull/8540 and https://github.com/rust-lang/rust/pull/74923.

steffahn

comment created time in 5 days

pull request commentrust-lang/cargo

relax deprecated diagnostic message check

@bors r+ Let me know if you need assistance updating the submodule.

euclio

comment created time in 5 days

issue commentrust-lang/cargo

network zlib stream error confusion

I found I had an extra copy of the problematic index. I have posted a repro here: https://github.com/ehuss/zlib-repro

I haven't really figured out much so far. The git_mwindow stuff is kinda wonky, and the window sizes on 32-bit are a lot different from 64-bit. In 64-bit, the window is fairly consistent (the entire size of the pack file which is 76,488,803 bytes). But in 32-bit, the sizes change a lot, I can't figure out what it is doing. The uncompressed size of all the git objects is about 1.9G, so that seems suspiciously close to the max signed 32-bit integer.

ehuss

comment created time in 5 days

push eventehuss/zlib-repro

Eric Huss

commit sha 2dead0e30b2684dd9de19f0e9e9927b71991a959

Add lock

view details

push time in 5 days

create barnchehuss/zlib-repro

branch : master

created branch time in 5 days

created repositoryehuss/zlib-repro

created time in 5 days

more