New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deprecate `std::env::home_dir` and fix incorrect documentation #51656

Merged
merged 1 commit into from Jul 7, 2018

Conversation

Projects
None yet
@soc
Contributor

soc commented Jun 20, 2018

Compare std::env::home_dirs claim:

Returns the value of the 'HOME' environment variable if it is set and not equal to the empty string.

... with its actual behavior:

std::env::set_var("HOME", "");
println!("{:?}", std::env::var_os("HOME")); // Some("")
println!("{:?}", std::env::home_dir());     // Some("")

The implementation is incorrect in two cases:

  • $HOME is set, but empty.
  • An entry for the user exists in /etc/passwd, but it's pw_dir is empty.

In both cases Rust considers an empty string to be a valid home directory. This contradicts the documentation, and is wrong in general.

@rust-highfive

This comment has been minimized.

Show comment
Hide comment
@rust-highfive

rust-highfive Jun 20, 2018

Collaborator

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @shepmaster (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

Collaborator

rust-highfive commented Jun 20, 2018

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @shepmaster (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

@soc

This comment has been minimized.

Show comment
Hide comment

@soc soc changed the title from Fix unix implementation of std::env::home_dir() to follow documentation to Fix Unix implementation of std::env::home_dir() to follow documentation Jun 20, 2018

@shepmaster

This comment has been minimized.

Show comment
Hide comment
@shepmaster

shepmaster Jun 20, 2018

Member

The code seems reasonable to me, but I'm unclear on if such a change is acceptable.

randomly reassigning to...

r? @KodrAus

Member

shepmaster commented Jun 20, 2018

The code seems reasonable to me, but I'm unclear on if such a change is acceptable.

randomly reassigning to...

r? @KodrAus

@rust-highfive rust-highfive assigned KodrAus and unassigned shepmaster Jun 20, 2018

@frewsxcv frewsxcv added the T-libs label Jun 20, 2018

@KodrAus

This comment has been minimized.

Show comment
Hide comment
@KodrAus

KodrAus Jun 21, 2018

So it looks like the docs were correct once upon a time, but since we stabilized with the current behaviour I think I'd be more comfortable updating the docs to reflect that, unless we do have the described behaviour on Windows.

KodrAus commented Jun 21, 2018

So it looks like the docs were correct once upon a time, but since we stabilized with the current behaviour I think I'd be more comfortable updating the docs to reflect that, unless we do have the described behaviour on Windows.

@soc

This comment has been minimized.

Show comment
Hide comment
@soc

soc Jun 21, 2018

Contributor

@KodrAus Windows is comparably broken (just in different ways) – see https://internals.rust-lang.org/t/deprecate-or-break-fix-std-env-home-dir/7315.

Preferably, I'd fix all the issues, but fixing the bugs on Windows has already been rejected. May it be possible to reevaluate the earlier decision given the new circumstances?

Contributor

soc commented Jun 21, 2018

@KodrAus Windows is comparably broken (just in different ways) – see https://internals.rust-lang.org/t/deprecate-or-break-fix-std-env-home-dir/7315.

Preferably, I'd fix all the issues, but fixing the bugs on Windows has already been rejected. May it be possible to reevaluate the earlier decision given the new circumstances?

@soc

This comment has been minimized.

Show comment
Hide comment
@soc

soc Jun 21, 2018

Contributor

The reason I'm trying to figure out what's the position here is because I want to work on rust-lang/cargo#5183, which is blocked by the 1.0 release of the dirs/directories crates, which are in turn blocked by the current home_dir situation.

From a user/third-party library author perspective I pretty much have three options:

  1. Keep dirs::home_dir() -> PathBuf calling env::home_dir().unwrap() on Unix-likes. This means:
  • Live with the incorrect behavior on Unix.
  • Use my own implementation for Windows, because env::home_dir is just too broken on Windows.
  • Not having to maintain code for are large number of niche systems which I won't be able to test.
  1. Copy the implementation of env::home_dir and fix the bugs
  • Change the result type of dirs::home_dir from PathBuf to Option<PathBuf>, because there are now realistic cases where home_dir can fail.
  • Correct implementation on both Unix and Windows.
  • Large maintenance burden for all the different platforms that env::home_dir was supposed to cover.
  1. Fix env::home_dir to make sense and simply use it in dirs and directories.
  • Able to drop workarounds for Windows.
  • No workarounds necessary on Linux.
  • Everyone benefits, not just me.

I'd really prefer it if we could make 3. work, although I'm slowly approaching the pain threshold of further delaying 1.0 releases for the crates and the things they keep blocking down the line. So I'd appreciate some communication about whether hoping for fixes is realistic.

Contributor

soc commented Jun 21, 2018

The reason I'm trying to figure out what's the position here is because I want to work on rust-lang/cargo#5183, which is blocked by the 1.0 release of the dirs/directories crates, which are in turn blocked by the current home_dir situation.

From a user/third-party library author perspective I pretty much have three options:

  1. Keep dirs::home_dir() -> PathBuf calling env::home_dir().unwrap() on Unix-likes. This means:
  • Live with the incorrect behavior on Unix.
  • Use my own implementation for Windows, because env::home_dir is just too broken on Windows.
  • Not having to maintain code for are large number of niche systems which I won't be able to test.
  1. Copy the implementation of env::home_dir and fix the bugs
  • Change the result type of dirs::home_dir from PathBuf to Option<PathBuf>, because there are now realistic cases where home_dir can fail.
  • Correct implementation on both Unix and Windows.
  • Large maintenance burden for all the different platforms that env::home_dir was supposed to cover.
  1. Fix env::home_dir to make sense and simply use it in dirs and directories.
  • Able to drop workarounds for Windows.
  • No workarounds necessary on Linux.
  • Everyone benefits, not just me.

I'd really prefer it if we could make 3. work, although I'm slowly approaching the pain threshold of further delaying 1.0 releases for the crates and the things they keep blocking down the line. So I'd appreciate some communication about whether hoping for fixes is realistic.

@steveklabnik

This comment has been minimized.

Show comment
Hide comment
@steveklabnik

steveklabnik Jun 21, 2018

Member

Nominating for @rust-lang/libs discussion, as they'd have to sign off on major changes here.

Member

steveklabnik commented Jun 21, 2018

Nominating for @rust-lang/libs discussion, as they'd have to sign off on major changes here.

@SimonSapin

This comment has been minimized.

Show comment
Hide comment
@SimonSapin

SimonSapin Jun 21, 2018

Contributor

Do we know of a situation other than a test case where the environment variable might exist and be empty?

Contributor

SimonSapin commented Jun 21, 2018

Do we know of a situation other than a test case where the environment variable might exist and be empty?

@soc

This comment has been minimized.

Show comment
Hide comment
@SimonSapin

This comment has been minimized.

Show comment
Hide comment
@SimonSapin

SimonSapin Jun 21, 2018

Contributor

@soc (Assuming this is in response to me.) This post mentions not having a home directory. Is $HOME typically the empty string in that case, rather than unset?

Contributor

SimonSapin commented Jun 21, 2018

@soc (Assuming this is in response to me.) This post mentions not having a home directory. Is $HOME typically the empty string in that case, rather than unset?

@soc

This comment has been minimized.

Show comment
Hide comment
@soc

soc Jun 22, 2018

Contributor

@SimonSapin It depends. It seems like creating a user and using the flags to not create a home directory usually causes some non-existing dir to end up in /etc/passwd. That may depend on the tool being used, though.
$HOME is usually derived from that and there is nothing preventing someone from having an entry like

soc:x:1001:1001:::/bin/false

std::env::home_dir should not pretend that there is some valid home directory in that case by returning Some("").

Contributor

soc commented Jun 22, 2018

@SimonSapin It depends. It seems like creating a user and using the flags to not create a home directory usually causes some non-existing dir to end up in /etc/passwd. That may depend on the tool being used, though.
$HOME is usually derived from that and there is nothing preventing someone from having an entry like

soc:x:1001:1001:::/bin/false

std::env::home_dir should not pretend that there is some valid home directory in that case by returning Some("").

@SimonSapin

This comment has been minimized.

Show comment
Hide comment
@SimonSapin

SimonSapin Jun 27, 2018

Contributor

The libs team discussed this today and consensus was that, since this function is already not doing what people want on Windows, we’d rather deprecate it in favor of something on crates.io and not change its behavior.

@rfcbot fcp close

Contributor

SimonSapin commented Jun 27, 2018

The libs team discussed this today and consensus was that, since this function is already not doing what people want on Windows, we’d rather deprecate it in favor of something on crates.io and not change its behavior.

@rfcbot fcp close

@rfcbot

This comment has been minimized.

Show comment
Hide comment
@rfcbot

rfcbot Jun 27, 2018

Team member @SimonSapin has proposed to close this. The next step is review by the rest of the tagged teams:

No concerns currently listed.

Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

rfcbot commented Jun 27, 2018

Team member @SimonSapin has proposed to close this. The next step is review by the rest of the tagged teams:

No concerns currently listed.

Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

@soc

This comment has been minimized.

Show comment
Hide comment
@soc

soc Jul 5, 2018

Contributor

I released 1.0 versions of dirs and directories with correct implementations of home_dir. What needs to be done here now?

Shall I change this PR to deprecate std::env::home_dir?

Contributor

soc commented Jul 5, 2018

I released 1.0 versions of dirs and directories with correct implementations of home_dir. What needs to be done here now?

Shall I change this PR to deprecate std::env::home_dir?

@SimonSapin

This comment has been minimized.

Show comment
Hide comment
@SimonSapin

SimonSapin Jul 5, 2018

Contributor

@soc Thank you for your work on this. Would dirs::home_dir be the most similar "replacement" for std::env::home_dir?

Contributor

SimonSapin commented Jul 5, 2018

@soc Thank you for your work on this. Would dirs::home_dir be the most similar "replacement" for std::env::home_dir?

@soc

This comment has been minimized.

Show comment
Hide comment
@soc

soc Jul 5, 2018

Contributor

@SimonSapin I'd say so.

The implementation of home_dir is here: https://github.com/soc/dirs-rs/blob/master/src/unix.rs#L14 and practically identical to the fixes proposed here (the only change is that I can't use Option::filter()).

The Windows implementation of it is here: https://github.com/soc/dirs-rs/blob/master/src/win.rs#L32.
Here the difference is that it doesn't (incorrectly) consider a HOME env var on Windows when determining the home directory. Whether it should consider the USERPROFILE env var is a question which is open to debate and I'm happy to listen to pro and cons.

Contributor

soc commented Jul 5, 2018

@SimonSapin I'd say so.

The implementation of home_dir is here: https://github.com/soc/dirs-rs/blob/master/src/unix.rs#L14 and practically identical to the fixes proposed here (the only change is that I can't use Option::filter()).

The Windows implementation of it is here: https://github.com/soc/dirs-rs/blob/master/src/win.rs#L32.
Here the difference is that it doesn't (incorrectly) consider a HOME env var on Windows when determining the home directory. Whether it should consider the USERPROFILE env var is a question which is open to debate and I'm happy to listen to pro and cons.

@SimonSapin

This comment has been minimized.

Show comment
Hide comment
@SimonSapin

SimonSapin Jul 5, 2018

Contributor

Shall I change this PR to deprecate std::env::home_dir?

Yes, please do with a deprecation message along the lines of: “consider using the home_dir function from https://crates.io/crates/dirs instead”

Contributor

SimonSapin commented Jul 5, 2018

Shall I change this PR to deprecate std::env::home_dir?

Yes, please do with a deprecation message along the lines of: “consider using the home_dir function from https://crates.io/crates/dirs instead”

@soc

This comment has been minimized.

Show comment
Hide comment
@soc

soc Jul 5, 2018

Contributor

@SimonSapin Shall I also fix the documentation to describe the current behavior?

Is

#[deprecated(since = "1.28.0",
    note="This function's behavior is probably not what you want. Consider using the home_dir function from crates.io/crates/dirs instead.")]

referring to the correct version?

Contributor

soc commented Jul 5, 2018

@SimonSapin Shall I also fix the documentation to describe the current behavior?

Is

#[deprecated(since = "1.28.0",
    note="This function's behavior is probably not what you want. Consider using the home_dir function from crates.io/crates/dirs instead.")]

referring to the correct version?

@soc soc changed the title from Fix Unix implementation of std::env::home_dir() to follow documentation to Deprecate `std::env::home_dir` and fix incorrect documentation Jul 5, 2018

@soc

This comment has been minimized.

Show comment
Hide comment
@soc

soc Jul 5, 2018

Contributor

@SimonSapin I just pushed the deprecation into this PR, could you have a look? Thanks!

Contributor

soc commented Jul 5, 2018

@SimonSapin I just pushed the deprecation into this PR, could you have a look? Thanks!

@rust-highfive

This comment has been minimized.

Show comment
Hide comment
@rust-highfive

rust-highfive Jul 5, 2018

Collaborator

The job x86_64-gnu-llvm-3.9 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.
[00:03:43]    Compiling std_unicode v0.0.0 (file:///checkout/src/libstd_unicode)
[00:03:44]    Compiling alloc_system v0.0.0 (file:///checkout/src/liballoc_system)
[00:03:44]    Compiling panic_abort v0.0.0 (file:///checkout/src/libpanic_abort)
[00:03:48]    Compiling panic_unwind v0.0.0 (file:///checkout/src/libpanic_unwind)
[00:03:50] error: `#[deprecated]` cannot be used in staged api, use `#[rustc_deprecated]` instead
[00:03:50]    --> libstd/env.rs:541:1
[00:03:50]     |
[00:03:50] 541 | / pub fn home_dir() -> Option<PathBuf> {
[00:03:50] 542 | |     os_imp::home_dir()
[00:03:50]     | |_^
[00:03:50] 
[00:03:52] error: aborting due to previous error
[00:03:52] 
[00:03:52] 
[00:03:52] error: Could not compile `std`.
[00:03:52] 
[00:03:52] Caused by:
[00:03:52]   process didn't exit successfully: `/checkout/obj/build/bootstrap/debug/rustc --crate-name std libstd/lib.rs --color always --error-format json --crate-type dylib --crate-type rlib --emit=dep-info,link -C prefer-dynamic -C opt-level=2 --cfg feature="alloc_jemalloc" --cfg feature="backtrace" --cfg feature="jemalloc" --cfg feature="panic-unwind" --cfg feature="panic_unwind" -C metadata=dcc25629039acb53 -C extra-filename=-dcc25629039acb53 --out-dir /checkout/obj/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps --target x86_64-unknown-linux-gnu -L dependency=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps -L dependency=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-std/release/deps --extern alloc=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/liballoc-dab08365760adda8.rlib --extern alloc_jemalloc=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/liballoc_jemalloc-2bfe3082744c992b.rlib --extern alloc_system=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/liballoc_system-19594d83bbdd6633.rlib --extern compiler_builtins=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/libcompiler_builtins-8c383f2d2bbbcb1d.rlib --extern core=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/libcore-c8f7a210a5d40dd6.rlib --extern libc=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/liblibc-e67af0f0fda6d67c.rlib --extern panic_abort=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/libpanic_abort-25d6bfec677c2cc1.rlib --extern panic_unwind=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/libpanic_unwind-df29f51552b7081c.rlib --extern rustc_asan=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/librustc_asan-19acac464f503382.rlib --extern rustc_lsan=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/librustc_lsan-1691bf078a2ccad2.rlib --extern rustc_msan=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/librustc_msan-ed6ca6bad7af674f.rlib --extern rustc_tsan=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/librustc_tsan-1f2e12e7aa536e40.rlib --extern std_unicode=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/libstd_unicode-354a9da054095dd7.rlib --extern unwind=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/libunwind-45eff864955bd111.rlib -L native=/checkout/obj/build/x86_64-unknown-linux-gnu/native/libbacktrace/ -L native=/checkout/obj/build/x86_64-unknown-linux-gnu/native/libbacktrace -l static=backtrace -l static=backtrace -l dl -l rt -l pthread -L native=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/build/compiler_builtins-c2bb2884be27c6a0/out -L native=/checkout/obj/build/x86_64-unknown-linux-gnu/native/jemalloc/lib` (exit code: 101)
[00:03:52] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "build" "--target" "x86_64-unknown-linux-gnu" "-j" "4" "--release" "--locked" "--color" "always" "--features" "panic-unwind jemalloc backtrace" "--manifest-path" "/checkout/src/libstd/Cargo.toml" "--message-format" "json"
[00:03:52] expected success, got: exit code: 101
[00:03:52] thread 'main' panicked at 'cargo must succeed', bootstrap/compile.rs:1117:9
[00:03:52] travis_fold:end:stage0-std

[00:03:52] travis_time:end:stage0-std:start=1530805341727853393,finish=1530805375540274803,duration=33812421410


[00:03:52] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test src/tools/tidy
[00:03:52] Build completed unsuccessfully in 0:00:35
[00:03:52] Makefile:79: recipe for target 'tidy' failed
[00:03:52] make: *** [tidy] Error 1

The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:0e9428c5
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)
---
travis_time:end:13de3575:start=1530805376051939333,finish=1530805376058971787,duration=7032454
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:1125a87e
$ head -30 ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers || true
head: cannot open ‘./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers’ for reading: No such file or directory
travis_fold:end:after_failure.4
travis_fold:start:after_failure.5
travis_time:start:19f21240
$ dmesg | grep -i kill

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

Collaborator

rust-highfive commented Jul 5, 2018

The job x86_64-gnu-llvm-3.9 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.
[00:03:43]    Compiling std_unicode v0.0.0 (file:///checkout/src/libstd_unicode)
[00:03:44]    Compiling alloc_system v0.0.0 (file:///checkout/src/liballoc_system)
[00:03:44]    Compiling panic_abort v0.0.0 (file:///checkout/src/libpanic_abort)
[00:03:48]    Compiling panic_unwind v0.0.0 (file:///checkout/src/libpanic_unwind)
[00:03:50] error: `#[deprecated]` cannot be used in staged api, use `#[rustc_deprecated]` instead
[00:03:50]    --> libstd/env.rs:541:1
[00:03:50]     |
[00:03:50] 541 | / pub fn home_dir() -> Option<PathBuf> {
[00:03:50] 542 | |     os_imp::home_dir()
[00:03:50]     | |_^
[00:03:50] 
[00:03:52] error: aborting due to previous error
[00:03:52] 
[00:03:52] 
[00:03:52] error: Could not compile `std`.
[00:03:52] 
[00:03:52] Caused by:
[00:03:52]   process didn't exit successfully: `/checkout/obj/build/bootstrap/debug/rustc --crate-name std libstd/lib.rs --color always --error-format json --crate-type dylib --crate-type rlib --emit=dep-info,link -C prefer-dynamic -C opt-level=2 --cfg feature="alloc_jemalloc" --cfg feature="backtrace" --cfg feature="jemalloc" --cfg feature="panic-unwind" --cfg feature="panic_unwind" -C metadata=dcc25629039acb53 -C extra-filename=-dcc25629039acb53 --out-dir /checkout/obj/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps --target x86_64-unknown-linux-gnu -L dependency=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps -L dependency=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-std/release/deps --extern alloc=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/liballoc-dab08365760adda8.rlib --extern alloc_jemalloc=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/liballoc_jemalloc-2bfe3082744c992b.rlib --extern alloc_system=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/liballoc_system-19594d83bbdd6633.rlib --extern compiler_builtins=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/libcompiler_builtins-8c383f2d2bbbcb1d.rlib --extern core=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/libcore-c8f7a210a5d40dd6.rlib --extern libc=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/liblibc-e67af0f0fda6d67c.rlib --extern panic_abort=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/libpanic_abort-25d6bfec677c2cc1.rlib --extern panic_unwind=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/libpanic_unwind-df29f51552b7081c.rlib --extern rustc_asan=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/librustc_asan-19acac464f503382.rlib --extern rustc_lsan=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/librustc_lsan-1691bf078a2ccad2.rlib --extern rustc_msan=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/librustc_msan-ed6ca6bad7af674f.rlib --extern rustc_tsan=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/librustc_tsan-1f2e12e7aa536e40.rlib --extern std_unicode=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/libstd_unicode-354a9da054095dd7.rlib --extern unwind=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/libunwind-45eff864955bd111.rlib -L native=/checkout/obj/build/x86_64-unknown-linux-gnu/native/libbacktrace/ -L native=/checkout/obj/build/x86_64-unknown-linux-gnu/native/libbacktrace -l static=backtrace -l static=backtrace -l dl -l rt -l pthread -L native=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/build/compiler_builtins-c2bb2884be27c6a0/out -L native=/checkout/obj/build/x86_64-unknown-linux-gnu/native/jemalloc/lib` (exit code: 101)
[00:03:52] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "build" "--target" "x86_64-unknown-linux-gnu" "-j" "4" "--release" "--locked" "--color" "always" "--features" "panic-unwind jemalloc backtrace" "--manifest-path" "/checkout/src/libstd/Cargo.toml" "--message-format" "json"
[00:03:52] expected success, got: exit code: 101
[00:03:52] thread 'main' panicked at 'cargo must succeed', bootstrap/compile.rs:1117:9
[00:03:52] travis_fold:end:stage0-std

[00:03:52] travis_time:end:stage0-std:start=1530805341727853393,finish=1530805375540274803,duration=33812421410


[00:03:52] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test src/tools/tidy
[00:03:52] Build completed unsuccessfully in 0:00:35
[00:03:52] Makefile:79: recipe for target 'tidy' failed
[00:03:52] make: *** [tidy] Error 1

The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:0e9428c5
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)
---
travis_time:end:13de3575:start=1530805376051939333,finish=1530805376058971787,duration=7032454
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:1125a87e
$ head -30 ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers || true
head: cannot open ‘./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers’ for reading: No such file or directory
travis_fold:end:after_failure.4
travis_fold:start:after_failure.5
travis_time:start:19f21240
$ dmesg | grep -i kill

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

@soc

This comment has been minimized.

Show comment
Hide comment
@soc

soc Jul 5, 2018

Contributor

Thanks @rust-highfive, I changed deprecated to rustc_deprecated. Let's give this another try.

Contributor

soc commented Jul 5, 2018

Thanks @rust-highfive, I changed deprecated to rustc_deprecated. Let's give this another try.

@rust-highfive

This comment has been minimized.

Show comment
Hide comment
@rust-highfive

rust-highfive Jul 5, 2018

Collaborator

The job x86_64-gnu-llvm-3.9 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.
[00:03:44]    Compiling std_unicode v0.0.0 (file:///checkout/src/libstd_unicode)
[00:03:45]    Compiling alloc_system v0.0.0 (file:///checkout/src/liballoc_system)
[00:03:45]    Compiling panic_abort v0.0.0 (file:///checkout/src/libpanic_abort)
[00:03:50]    Compiling panic_unwind v0.0.0 (file:///checkout/src/libpanic_unwind)
[00:03:52] error[E0541]: unknown meta item 'note'
[00:03:52]    --> libstd/env.rs:539:5
[00:03:52]     |
[00:03:52] 539 |     note="This function's behavior is unexpected and probably not what you want. Consider using the home_dir function from crates.io/crates/dirs instead.")]
[00:03:52] 
[00:03:54] error: aborting due to previous error
[00:03:54] 
[00:03:54] For more information about this error, try `rustc --explain E0541`.
[00:03:54] For more information about this error, try `rustc --explain E0541`.
[00:03:54] error: Could not compile `std`.
[00:03:54] 
[00:03:54] Caused by:
[00:03:54]   process didn't exit successfully: `/checkout/obj/build/bootstrap/debug/rustc --crate-name std libstd/lib.rs --color always --error-format json --crate-type dylib --crate-type rlib --emit=dep-info,link -C prefer-dynamic -C opt-level=2 --cfg feature="alloc_jemalloc" --cfg feature="backtrace" --cfg feature="jemalloc" --cfg feature="panic-unwind" --cfg feature="panic_unwind" -C metadata=dcc25629039acb53 -C extra-filename=-dcc25629039acb53 --out-dir /checkout/obj/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps --target x86_64-unknown-linux-gnu -L dependency=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps -L dependency=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-std/release/deps --extern alloc=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/liballoc-dab08365760adda8.rlib --extern alloc_jemalloc=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/liballoc_jemalloc-2bfe3082744c992b.rlib --extern alloc_system=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/liballoc_system-19594d83bbdd6633.rlib --extern compiler_builtins=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/libcompiler_builtins-8c383f2d2bbbcb1d.rlib --extern core=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/libcore-c8f7a210a5d40dd6.rlib --extern libc=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/liblibc-e67af0f0fda6d67c.rlib --extern panic_abort=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/libpanic_abort-25d6bfec677c2cc1.rlib --extern panic_unwind=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/libpanic_unwind-df29f51552b7081c.rlib --extern rustc_asan=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/librustc_asan-19acac464f503382.rlib --extern rustc_lsan=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/librustc_lsan-1691bf078a2ccad2.rlib --extern rustc_msan=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/librustc_msan-ed6ca6bad7af674f.rlib --extern rustc_tsan=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/librustc_tsan-1f2e12e7aa536e40.rlib --extern std_unicode=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/libstd_unicode-354a9da054095dd7.rlib --extern unwind=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/libunwind-45eff864955bd111.rlib -L native=/checkout/obj/build/x86_64-unknown-linux-gnu/native/libbacktrace/ -L native=/checkout/obj/build/x86_64-unknown-linux-gnu/native/libbacktrace -l static=backtrace -l static=backtrace -l dl -l rt -l pthread -L native=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/build/compiler_builtins-c2bb2884be27c6a0/out -L native=/checkout/obj/build/x86_64-unknown-linux-gnu/native/jemalloc/lib` (exit code: 101)
[00:03:54] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "build" "--target" "x86_64-unknown-linux-gnu" "-j" "4" "--release" "--locked" "--color" "always" "--features" "panic-unwind jemalloc backtrace" "--manifest-path" "/checkout/src/libstd/Cargo.toml" "--message-format" "json"
[00:03:54] expected success, got: exit code: 101
[00:03:54] thread 'main' panicked at 'cargo must succeed', bootstrap/compile.rs:1117:9
[00:03:54] travis_fold:end:stage0-std

[00:03:54] travis_time:end:stage0-std:start=1530805938825957173,finish=1530805976928021299,duration=38102064126


[00:03:54] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test src/tools/tidy
[00:03:54] Build completed unsuccessfully in 0:00:39
[00:03:54] Makefile:79: recipe for target 'tidy' failed
[00:03:54] make: *** [tidy] Error 1

The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:1b4ae52d
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)
---
travis_time:end:026f4715:start=1530805977476960381,finish=1530805977485020811,duration=8060430
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:030b3340
$ head -30 ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers || true
head: cannot open ‘./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers’ for reading: No such file or directory
travis_fold:end:after_failure.4
travis_fold:start:after_failure.5
travis_time:start:0970292c
$ dmesg | grep -i kill

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

Collaborator

rust-highfive commented Jul 5, 2018

The job x86_64-gnu-llvm-3.9 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.
[00:03:44]    Compiling std_unicode v0.0.0 (file:///checkout/src/libstd_unicode)
[00:03:45]    Compiling alloc_system v0.0.0 (file:///checkout/src/liballoc_system)
[00:03:45]    Compiling panic_abort v0.0.0 (file:///checkout/src/libpanic_abort)
[00:03:50]    Compiling panic_unwind v0.0.0 (file:///checkout/src/libpanic_unwind)
[00:03:52] error[E0541]: unknown meta item 'note'
[00:03:52]    --> libstd/env.rs:539:5
[00:03:52]     |
[00:03:52] 539 |     note="This function's behavior is unexpected and probably not what you want. Consider using the home_dir function from crates.io/crates/dirs instead.")]
[00:03:52] 
[00:03:54] error: aborting due to previous error
[00:03:54] 
[00:03:54] For more information about this error, try `rustc --explain E0541`.
[00:03:54] For more information about this error, try `rustc --explain E0541`.
[00:03:54] error: Could not compile `std`.
[00:03:54] 
[00:03:54] Caused by:
[00:03:54]   process didn't exit successfully: `/checkout/obj/build/bootstrap/debug/rustc --crate-name std libstd/lib.rs --color always --error-format json --crate-type dylib --crate-type rlib --emit=dep-info,link -C prefer-dynamic -C opt-level=2 --cfg feature="alloc_jemalloc" --cfg feature="backtrace" --cfg feature="jemalloc" --cfg feature="panic-unwind" --cfg feature="panic_unwind" -C metadata=dcc25629039acb53 -C extra-filename=-dcc25629039acb53 --out-dir /checkout/obj/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps --target x86_64-unknown-linux-gnu -L dependency=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps -L dependency=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-std/release/deps --extern alloc=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/liballoc-dab08365760adda8.rlib --extern alloc_jemalloc=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/liballoc_jemalloc-2bfe3082744c992b.rlib --extern alloc_system=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/liballoc_system-19594d83bbdd6633.rlib --extern compiler_builtins=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/libcompiler_builtins-8c383f2d2bbbcb1d.rlib --extern core=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/libcore-c8f7a210a5d40dd6.rlib --extern libc=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/liblibc-e67af0f0fda6d67c.rlib --extern panic_abort=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/libpanic_abort-25d6bfec677c2cc1.rlib --extern panic_unwind=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/libpanic_unwind-df29f51552b7081c.rlib --extern rustc_asan=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/librustc_asan-19acac464f503382.rlib --extern rustc_lsan=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/librustc_lsan-1691bf078a2ccad2.rlib --extern rustc_msan=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/librustc_msan-ed6ca6bad7af674f.rlib --extern rustc_tsan=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/librustc_tsan-1f2e12e7aa536e40.rlib --extern std_unicode=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/libstd_unicode-354a9da054095dd7.rlib --extern unwind=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/libunwind-45eff864955bd111.rlib -L native=/checkout/obj/build/x86_64-unknown-linux-gnu/native/libbacktrace/ -L native=/checkout/obj/build/x86_64-unknown-linux-gnu/native/libbacktrace -l static=backtrace -l static=backtrace -l dl -l rt -l pthread -L native=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/build/compiler_builtins-c2bb2884be27c6a0/out -L native=/checkout/obj/build/x86_64-unknown-linux-gnu/native/jemalloc/lib` (exit code: 101)
[00:03:54] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "build" "--target" "x86_64-unknown-linux-gnu" "-j" "4" "--release" "--locked" "--color" "always" "--features" "panic-unwind jemalloc backtrace" "--manifest-path" "/checkout/src/libstd/Cargo.toml" "--message-format" "json"
[00:03:54] expected success, got: exit code: 101
[00:03:54] thread 'main' panicked at 'cargo must succeed', bootstrap/compile.rs:1117:9
[00:03:54] travis_fold:end:stage0-std

[00:03:54] travis_time:end:stage0-std:start=1530805938825957173,finish=1530805976928021299,duration=38102064126


[00:03:54] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test src/tools/tidy
[00:03:54] Build completed unsuccessfully in 0:00:39
[00:03:54] Makefile:79: recipe for target 'tidy' failed
[00:03:54] make: *** [tidy] Error 1

The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:1b4ae52d
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)
---
travis_time:end:026f4715:start=1530805977476960381,finish=1530805977485020811,duration=8060430
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:030b3340
$ head -30 ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers || true
head: cannot open ‘./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers’ for reading: No such file or directory
travis_fold:end:after_failure.4
travis_fold:start:after_failure.5
travis_time:start:0970292c
$ dmesg | grep -i kill

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

@rust-highfive

This comment has been minimized.

Show comment
Hide comment
@rust-highfive

rust-highfive Jul 5, 2018

Collaborator

The job x86_64-gnu-llvm-3.9 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.

[00:04:23] travis_fold:start:tidy
travis_time:start:tidy
tidy check
[00:04:23] tidy error: /checkout/src/libstd/env.rs:515: line longer than 100 chars
[00:04:23] tidy error: /checkout/src/libstd/env.rs:516: line longer than 100 chars
[00:04:23] tidy error: /checkout/src/libstd/env.rs:517: line longer than 100 chars
[00:04:23] tidy error: /checkout/src/libstd/env.rs:522: line longer than 100 chars
[00:04:23] tidy error: /checkout/src/libstd/env.rs:523: line longer than 100 chars
[00:04:23] tidy error: /checkout/src/libstd/env.rs:524: line longer than 100 chars
[00:04:23] tidy error: /checkout/src/libstd/env.rs:539: line longer than 100 chars
[00:04:25] some tidy checks failed
[00:04:25] 
[00:04:25] 
[00:04:25] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/tidy" "/checkout/src" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "--no-vendor" "--quiet"
[00:04:25] 
[00:04:25] 
[00:04:25] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test src/tools/tidy
[00:04:25] Build completed unsuccessfully in 0:01:30
[00:04:25] Build completed unsuccessfully in 0:01:30
[00:04:25] make: *** [tidy] Error 1
[00:04:25] Makefile:79: recipe for target 'tidy' failed

The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:2787f61e
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)
---
travis_time:end:0362a9e0:start=1530806593995927365,finish=1530806594003376588,duration=7449223
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:04e0f1c9
$ head -30 ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers || true
head: cannot open ‘./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers’ for reading: No such file or directory
travis_fold:end:after_failure.4
travis_fold:start:after_failure.5
travis_time:start:03991a78
$ dmesg | grep -i kill

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

Collaborator

rust-highfive commented Jul 5, 2018

The job x86_64-gnu-llvm-3.9 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.

[00:04:23] travis_fold:start:tidy
travis_time:start:tidy
tidy check
[00:04:23] tidy error: /checkout/src/libstd/env.rs:515: line longer than 100 chars
[00:04:23] tidy error: /checkout/src/libstd/env.rs:516: line longer than 100 chars
[00:04:23] tidy error: /checkout/src/libstd/env.rs:517: line longer than 100 chars
[00:04:23] tidy error: /checkout/src/libstd/env.rs:522: line longer than 100 chars
[00:04:23] tidy error: /checkout/src/libstd/env.rs:523: line longer than 100 chars
[00:04:23] tidy error: /checkout/src/libstd/env.rs:524: line longer than 100 chars
[00:04:23] tidy error: /checkout/src/libstd/env.rs:539: line longer than 100 chars
[00:04:25] some tidy checks failed
[00:04:25] 
[00:04:25] 
[00:04:25] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/tidy" "/checkout/src" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "--no-vendor" "--quiet"
[00:04:25] 
[00:04:25] 
[00:04:25] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test src/tools/tidy
[00:04:25] Build completed unsuccessfully in 0:01:30
[00:04:25] Build completed unsuccessfully in 0:01:30
[00:04:25] make: *** [tidy] Error 1
[00:04:25] Makefile:79: recipe for target 'tidy' failed

The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:2787f61e
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)
---
travis_time:end:0362a9e0:start=1530806593995927365,finish=1530806594003376588,duration=7449223
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:04e0f1c9
$ head -30 ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers || true
head: cannot open ‘./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers’ for reading: No such file or directory
travis_fold:end:after_failure.4
travis_fold:start:after_failure.5
travis_time:start:03991a78
$ dmesg | grep -i kill

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

@soc

This comment has been minimized.

Show comment
Hide comment
@soc

soc Jul 6, 2018

Contributor

@SimonSapin Done!

Contributor

soc commented Jul 6, 2018

@SimonSapin Done!

@SimonSapin

This comment has been minimized.

Show comment
Hide comment
@SimonSapin

SimonSapin Jul 6, 2018

Contributor

@bors r+

Contributor

SimonSapin commented Jul 6, 2018

@bors r+

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Jul 6, 2018

Contributor

📌 Commit 0afc16a has been approved by SimonSapin

Contributor

bors commented Jul 6, 2018

📌 Commit 0afc16a has been approved by SimonSapin

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Jul 7, 2018

Contributor

⌛️ Testing commit 0afc16a with merge 99b0ddb...

Contributor

bors commented Jul 7, 2018

⌛️ Testing commit 0afc16a with merge 99b0ddb...

bors added a commit that referenced this pull request Jul 7, 2018

Auto merge of #51656 - soc:topic/fix-home-dir, r=SimonSapin
Deprecate `std::env::home_dir` and fix incorrect documentation

Compare `std::env::home_dir`s claim:

> Returns the value of the 'HOME' environment variable if it is set and not equal to the empty string.

... with its actual behavior:

```
std::env::set_var("HOME", "");
println!("{:?}", std::env::var_os("HOME")); // Some("")
println!("{:?}", std::env::home_dir());     // Some("")
```

The implementation is incorrect in two cases:
- `$HOME` is set, but empty.
- An entry for the user exists in `/etc/passwd`, but it's `pw_dir` is empty.

In both cases Rust considers an empty string to be a valid home directory. This contradicts the documentation, and is wrong in general.
@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Jul 7, 2018

Contributor

☀️ Test successful - status-appveyor, status-travis
Approved by: SimonSapin
Pushing 99b0ddb to master...

Contributor

bors commented Jul 7, 2018

☀️ Test successful - status-appveyor, status-travis
Approved by: SimonSapin
Pushing 99b0ddb to master...

@bors bors merged commit 0afc16a into rust-lang:master Jul 7, 2018

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
homu Test successful
Details

niklasad1 added a commit to paritytech/parity-ethereum that referenced this pull request Jul 9, 2018

Replace `std::env::home_dir` with `dirs::home_dir`
`std::env::home_dir` is deprecated but will probably take a while until
it is deprecated on stable. For more info see rust-lang/rust#51656

5chdn added a commit to paritytech/parity-ethereum that referenced this pull request Jul 9, 2018

Replace `std::env::home_dir` with `dirs::home_dir` (#9077)
`std::env::home_dir` is deprecated but will probably take a while until
it is deprecated on stable. For more info see rust-lang/rust#51656

dvdplm added a commit to paritytech/parity-common that referenced this pull request Jul 9, 2018

Replace `std::env::home_dir` with `dirs::home_dir` (#9077)
`std::env::home_dir` is deprecated but will probably take a while until
it is deprecated on stable. For more info see rust-lang/rust#51656

hoodie added a commit to ascii-dresden/asciii that referenced this pull request Jul 11, 2018

@tjkirch

This comment has been minimized.

Show comment
Hide comment
@tjkirch

tjkirch Jul 30, 2018

I don't understand this decision. Removing the API seems like a bigger breakage than fixing the behavior, particularly when it works in normal cases.

tjkirch commented Jul 30, 2018

I don't understand this decision. Removing the API seems like a bigger breakage than fixing the behavior, particularly when it works in normal cases.

@sfackler

This comment has been minimized.

Show comment
Hide comment
@sfackler

sfackler Jul 30, 2018

Member

Deprecation is not removal.

Member

sfackler commented Jul 30, 2018

Deprecation is not removal.

@tjkirch

This comment has been minimized.

Show comment
Hide comment
@tjkirch

tjkirch Jul 30, 2018

Deprecation usually implies future removal. And now anyone using this API gets yelled at by the compiler, and so can't maintain a clean build without bringing in a dependency.

tjkirch commented Jul 30, 2018

Deprecation usually implies future removal. And now anyone using this API gets yelled at by the compiler, and so can't maintain a clean build without bringing in a dependency.

@soc

This comment has been minimized.

Show comment
Hide comment
@soc

soc Jul 30, 2018

Contributor

@tjkirch Yeah, I'm not too happy with the decision. I'm now basically on the hook for supporting every platform ever invented under the sun, which I'm practically unable to test.

Contributor

soc commented Jul 30, 2018

@tjkirch Yeah, I'm not too happy with the decision. I'm now basically on the hook for supporting every platform ever invented under the sun, which I'm practically unable to test.

kornelski added a commit to mmstick/cargo-deb that referenced this pull request Aug 5, 2018

netbsd-srcmastr pushed a commit to NetBSD/pkgsrc that referenced this pull request Sep 14, 2018

rust: Update to 1.29.0.
Version 1.29.0 (2018-09-13)
==========================

Compiler
--------
- [Bumped minimum LLVM version to 5.0.][51899]
- [Added `powerpc64le-unknown-linux-musl` target.][51619]
- [Added `aarch64-unknown-hermit` and `x86_64-unknown-hermit` targets.][52861]

Libraries
---------
- [`Once::call_once` now no longer requires `Once` to be `'static`.][52239]
- [`BuildHasherDefault` now implements `PartialEq` and `Eq`.][52402]
- [`Box<CStr>`, `Box<OsStr>`, and `Box<Path>` now implement `Clone`.][51912]
- [Implemented `PartialEq<&str>` for `OsString` and `PartialEq<OsString>`
  for `&str`.][51178]
- [`Cell<T>` now allows `T` to be unsized.][50494]
- [`SocketAddr` is now stable on Redox.][52656]

Stabilized APIs
---------------
- [`Arc::downcast`]
- [`Iterator::flatten`]
- [`Rc::downcast`]

Cargo
-----
- [Cargo can silently fix some bad lockfiles ][cargo/5831] You can use
  `--locked` to disable this behaviour.
- [`cargo-install` will now allow you to cross compile an install
  using `--target`][cargo/5614]
- [Added the `cargo-fix` subcommand to automatically move project code from
  2015 edition to 2018.][cargo/5723]

Misc
----
- [`rustdoc` now has the `--cap-lints` option which demotes all lints above
  the specified level to that level.][52354] For example `--cap-lints warn`
  will demote `deny` and `forbid` lints to `warn`.
- [`rustc` and `rustdoc` will now have the exit code of `1` if compilation
  fails, and `101` if there is a panic.][52197]
- [A preview of clippy has been made available through rustup.][51122]
  You can install the preview with `rustup component add clippy-preview`

Compatibility Notes
-------------------
- [`str::{slice_unchecked, slice_unchecked_mut}` are now deprecated.][51807]
  Use `str::get_unchecked(begin..end)` instead.
- [`std::env::home_dir` is now deprecated for its unintuitive behaviour.][51656]
  Consider using the `home_dir` function from
  https://crates.io/crates/dirs instead.
- [`rustc` will no longer silently ignore invalid data in target spec.][52330]

[52861]: rust-lang/rust#52861
[52656]: rust-lang/rust#52656
[52239]: rust-lang/rust#52239
[52330]: rust-lang/rust#52330
[52354]: rust-lang/rust#52354
[52402]: rust-lang/rust#52402
[52103]: rust-lang/rust#52103
[52197]: rust-lang/rust#52197
[51807]: rust-lang/rust#51807
[51899]: rust-lang/rust#51899
[51912]: rust-lang/rust#51912
[51511]: rust-lang/rust#51511
[51619]: rust-lang/rust#51619
[51656]: rust-lang/rust#51656
[51178]: rust-lang/rust#51178
[51122]: rust-lang/rust#51122
[50494]: rust-lang/rust#50494
[cargo/5614]: rust-lang/cargo#5614
[cargo/5723]: rust-lang/cargo#5723
[cargo/5831]: rust-lang/cargo#5831
[`Arc::downcast`]: https://doc.rust-lang.org/std/sync/struct.Arc.html#method.downcast
[`Iterator::flatten`]: https://doc.rust-lang.org/std/iter/trait.Iterator.html#method.flatten
[`Rc::downcast`]: https://doc.rust-lang.org/std/rc/struct.Rc.html#method.downcast
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment