Link failure with 'undefined reference to [things in core/std/alloc]' between 1.37.0 and 1.41.0

[GinjaNinja32]

Project: https://github.com/GinjaNinja32/rustbot
I'll have a go at reducing this down, but I'm not sure how successful I'll be; a previous attempt to minimise a bug-inducing case with this project resulted in a test project which successfully demonstrated the same error I was trying to replicate... on a compiler version the original code worked fine on. My project might just be cursed.

Current master (e9fa274) compiles fine on 1.36.0, fails with a massive (~750KB) link error on 1.37.0-1.41.0, works again on 1.42.0-beta.3 and nightly 2020-02-19

Commits prior to GinjaNinja32/rustbot@c546766 compile fine on all versions tested (1.36.0 to 1.41.0 inclusive, plus mentioned beta and nightly).

The link error has a lot of undefined references, all to things involving core, std, and alloc; the 5 most common reported errors (of 168 distinct, 2658 total "undefined reference to TYPE" errors) are:

279x undefined reference to <T as core::convert::From<T>>::from
205x undefined reference to <core::result::Result<T,E> as core::ops::try::Try>::into_result
188x undefined reference to core::fmt::ArgumentV1::new
164x undefined reference to <core::result::Result<T,E> as core::ops::try::Try>::from_error
117x undefined reference to std::panicking::begin_panic

The compiler versions this happens on seem to be the same as those for which #67070 causes execution failures before c546766; this may be a related issue to that one.

If I compile on c546766 to get the link error, then checkout the parent commit and build again without cargo clean, I get an ICE:

$ git checkout c546766
$ cargo clean && cargo +1.41.0 build
<link error>
$ git checkout HEAD~  # 54b8289
$ cargo +1.41.0 build
   Compiling rustbot v0.1.0 (/home/nyx/rustbot/rustbot)
error: internal compiler error: src/librustc/dep_graph/graph.rs:680: DepNode Hir(rustbot[47fa]::types[0]::Meta[0]::deinit[0]) should have been pre-allocated but wasn't.

thread 'rustc' panicked at 'Box<Any>', src/librustc_errors/lib.rs:905:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports

note: rustc 1.41.0 (5e1a79984 2020-01-27) running on x86_64-unknown-linux-gnu

note: compiler flags: -C prefer-dynamic -C debuginfo=2 -C incremental --crate-type dylib

note: some of the compiler flags provided by cargo are hidden

error: aborting due to previous error

error: could not compile `rustbot`.

To learn more, run the command again with --verbose.

I'm not sure if the ICE has been fixed since 1.41.0, since the only reproduction case I know of involves compiling an older commit without cargo clean-ing a previous failed compile on the same compiler version, and versions after 1.41.0 don't fail to compile the project.

Meta

rustc --version --verbose:

rustc 1.36.0 (a53f9df32 2019-07-03)
binary: rustc
commit-hash: a53f9df32fbb0b5f4382caaad8f1a46f36ea887c
commit-date: 2019-07-03
host: x86_64-unknown-linux-gnu
release: 1.36.0
LLVM version: 8.0

rustc 1.41.0 (5e1a79984 2020-01-27)
binary: rustc
commit-hash: 5e1a799842ba6ed4a57e91f7ab9435947482f7d8
commit-date: 2020-01-27
host: x86_64-unknown-linux-gnu
release: 1.41.0
LLVM version: 9.0

rustc 1.42.0-beta.3 (86f329b41 2020-02-07)
binary: rustc
commit-hash: 86f329b419dbac59da59e2ac7d6e21e5eb679ec7
commit-date: 2020-02-07
host: x86_64-unknown-linux-gnu
release: 1.42.0-beta.3
LLVM version: 9.0

rustc 1.43.0-nightly (7760cd0fb 2020-02-19)
binary: rustc
commit-hash: 7760cd0fbbbf2c59a625e075a5bdfa88b8e30f8a
commit-date: 2020-02-19
host: x86_64-unknown-linux-gnu
release: 1.43.0-nightly
LLVM version: 9.0

[mati865]

Fixed by #68277
Probably duplicate of #67276

[GinjaNinja32]

#62649 looks a lot like my ICE here, and going backwards from the problematic commit changes rustbot::types::Meta from a trait with fn deinit(...) to a struct with deinit: ..., very similar to the reproduction case found in that issue.

[pnkfelix]

The description here covers a lot of ground. Two elements that stick immediately out to me are close matches to bugs I investigated recently.

(both of which I believe are resolved)

triage: P-medium. Self-assigning to confirm resolution.

[Enselic]

Triage: Since there were no follow up comments, I think it is safe to assume this is indeed fixed, and that that issue can be closed as a duplicate to #62649.