Crater Run: Make tyvar_behind_raw_pointer an error

[mikeyhew]

In preparation for a crater run to determine its impact

[rust-highfive]

r? @estebank

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

[mikeyhew]

r? @nikomatsakis

[petrochenkov]

Forbid is better for testing existing lints, someone could allow it already.

[mikeyhew]

@petrochenkov good point, and some crates could do allow(warnings), right?

[kennytm]

@bors try

[bors]

⌛ Trying commit e4a93e4 with merge c5804ea...

[bors]

☀️ Test successful - status-travis
State: approved= try=True

[kennytm]

@aidanhs @Mark-Simulacrum crater run wanted.

[Mark-Simulacrum]

Crater run started.

[Mark-Simulacrum]

http://cargobomb-reports.s3.amazonaws.com/pr-46934/index.html (yes, the pr-# is wrong, but this should be the right run -- if not, let me know, we'll restart and rerun it).

[mikeyhew]

60 regressions – is that good? It's better than I expected, anyway. And is it safe to say that all of the "fixed" crates and any test-fail regressions were spurious?

@nikomatsakis what do the results tell you?

[nikomatsakis]

60 seems like a lot to me =) but it all depends on the details. Let me dig in a bit.

[nikomatsakis]

I got as far as link-0.1.0. Most of the results I've looked at look like legit, distinct regressions. Here are the ones I see that are spurious:

• cc-1.0.4
• conc-0.5.0
• crux-0.3.0
• ctx-0.2.0
• esprit-0.0.5
• gear-0.1.3
• hashconsing-0.3.0
• hornet-0.1.0
• kernel_density-0.0.1
• libfuzzy-sys-0.1.0

This merits some discussion and consideration, I think. Of course, the future compatibility warning may lead some people to migrate, but we may want to think about some special method resolution rules -- for example, giving inherent methods defined on *mut T some sort of special precedence.

[nikomatsakis]

Well, I think this PR has served its purpose, right? I'm going to close for now. (It's not meant to be merged, I don't think.)