Try to fix a perf regression by updating log

[MaloJaffre]

Upgrade log to 0.4 in multiple crates and cargo.
Cc: #47154.

[rust-highfive]

r? @arielb1

(rust_highfive has picked a reviewer for you, use r? to override)

[alexcrichton]

@bors: r+

[bors]

📌 Commit 773c60a has been approved by alexcrichton

[kennytm]

@bors p=4

(Try to see if this can reduce the recent timeout failures)

[bors]

⌛ Testing commit 773c60a98e971c4ceba6e7c1bfc0d0286eb1384a with merge fbc632342d9c510f4b01d79e7364f220b89165f2...

[bors]

💔 Test failed - status-appveyor

[kennytm]

A legit error caused by bad interaction between the C library libgit2 and the updated winapi on x86_64-pc-windows-gnu.

The gai_strerrorA function is undefined, probably because winapi 0.3 no longer automatically links to all Windows libraries (you need to opt-in for the features). In particular the feature ws2tcpip which imports winsock2.lib is optional. However libgit2-sys itself does not depend on winapi, so previously it was just "accidentally working"? cc @alexcrichton

   Compiling cargo v0.25.0 (file:///C:/projects/rust/src/tools/cargo)
error: linking with `gcc` failed: exit code: 1
  |
  = note: <snip>
  = note: C:\projects\rust\build\x86_64-pc-windows-gnu\stage2-tools\x86_64-pc-windows-gnu\release\deps\liblibgit2_sys-21cea83aba30ff6f.rlib(socket_stream.c.obj):socket_stream.c:(.text$socket_connect+0x187): undefined reference to `gai_strerrorA'
          collect2.exe: error: ld returned 1 exit status

[alexcrichton]

Could this try updating just log so we can deal with that error later?

[kennytm]

@alexcrichton We could deal with it later if we don't update cargo. (why the error is not caught in cargo's CI though?)

[alexcrichton]

Yeah it's fine to not update Cargo here, the perf impact, in theory, is mostly in rustc. As to why it's not caught in Cargo no idea myself, they're inevitably different in some way and it's only a matter of time until you add something which exposes it.

[MaloJaffre]

I've rebased and removed the cargo submodule update.

[kennytm]

@bors r=alexcrichton

[bors]

📌 Commit 3f073c4 has been approved by alexcrichton

[bors]

⌛ Testing commit 3f073c4 with merge ee220da...

[bors]

☀️ Test successful - status-appveyor, status-travis
Approved by: alexcrichton
Pushing ee220da to master...

[michaelwoerister]

It seems to have worked: http://perf.rust-lang.org/compare.html?start=8724337c233f593e9961609d8b0855d0ec2357a0&end=ee220daca345302c3277befee2732b6b2a5a711c&stat=wall-time

Awesome! Thank you, @MaloJaffre!

[MaloJaffre]

Does this needs to be beta-backported? (PR #46278 causing this regression was merged before the 1.24.0 beta release)

[michaelwoerister]

Does this needs to be beta-backported?

Good catch! Yes, I think the performance difference is big enough to warrant a backport.

[alexcrichton]

Tagging as accepted as this helps fix the regression

[nikomatsakis]

So I currently get log output like this:

DEBUG:<unknown>: run_on_mir: /home/nmatsakis/tmp/issue-47470.rs:12:5: 15:6
DEBUG:<unknown>: check_stmt: StorageLive(_2)
DEBUG:<unknown>: check_stmt: _2 = const 42u32
DEBUG:<unknown>: check_stmt: StorageLive(_3)
DEBUG:<unknown>: check_stmt: _3 = &'_#4r _2
DEBUG:<unknown>: check_stmt: _0 = &'_#5r (*_3)

in particular, the <unknown> parts used to be crate/module paths. Any idea why this is? Could it be related to upgrading log?

[alexcrichton]

@KodrAus hm do you know why that may be occurring?

[alexcrichton]

Ah I see, it's because we're using env_logger which links to the older version of log. @KodrAus out of curiosity, do you know when env_logger 0.5 will be ready which links to log 0.4?

[KodrAus]

@alexcrichton I'll get rust-cli/env_logger#53 merged and then push 0.5 along with some PRs for rustc and cargo and any other repos folks would like updated 👍