Audit deprecation lints and hardcoded warnings and turn most of them into errors in 2018 edition

[petrochenkov]

Most these are going to become errors in 2015 edition as well sooner or later, but since edition switch is an explicit opt in, it's a good opportunity to tie disabling of all the deprecated stuff to it as well.

The amount of additional required changes will be negligible compared to changes already required for 2018 migration, especially if we are counting "2018 idioms" in.

Additionally, hardcoded warnings are bad, mkay, and audit is also necessary to turn them into configurable lints or errors. (Most of the warnings are very old and predate the deprecation lint system, and fire only in very rare cases.)

How to: add some kind of flag to span_warn and deprecation lint machinery that's false by default and "false" means it's a hard error on 2018 edition. Explicit opt-out can be applied so that a lint/warning continues being a lint/warning even on 2018 edition.

Known lints/warnings requiring opt-out:

• Lint private_in_public, going to be removed when Tracking issue for RFC #2145: Type privacy and private-in-public lints  #48054 is implemented
• Hardcoded warning

  rust/src/libsyntax/parse/parser.rs

  Lines 2004 to 2005 in 942b384

  	self.diagnostic().struct_span_warn(self.prev_span, "unnecessary path disambiguator")
  	.span_label(self.prev_span, "try removing `::`").emit();

  , going to be removed when rustfmt is stable and packaged with rustc.
• Maybe more... waiting on audit.

[nikomatsakis]

Discussed in the @rust-lang/lang meeting. Some thoughts.

• Clearly, "future-compatibility warnings" can certainly become hard errors.
  • i.e., things that will become hard errors in 2015.
• In general, though, I'm a bit reluctant to add a bunch of new errors into the 2015 -> 2018 migration unless they have migration lints.
  • We've generally been trying to make the first edition relatively conservative when it comes to breakage in general -- it might be that future editions are more aggressive once we have the kinks worked out.

Anyway, it'd be good to see the list, is the TL;DR I suppose!

[nikomatsakis]

It seems like the time limit is approaching to make a move here.

[petrochenkov]

This is probably not a high priority.
I someone (e.g. me) comes up with a lint audit until RC2, then it would be good, otherwise - not a big deal.

[nikomatsakis]

Bumping to Rust 2018 Release milestone.

[nikomatsakis]

Removing from Rust 2018 release milestone. This might've been nice but I think we just don't have time right now for it, and I don't see us backporting such changes. (@petrochenkov feel free to re-open if you disagree)