]> git.lizzy.rs Git - rust.git/commitdiff
Auto merge of #75534 - Aaron1011:feature/new-future-breakage, r=pnkfelix
authorbors <bors@rust-lang.org>
Sun, 1 Nov 2020 16:52:28 +0000 (16:52 +0000)
committerbors <bors@rust-lang.org>
Sun, 1 Nov 2020 16:52:28 +0000 (16:52 +0000)
Implement rustc side of report-future-incompat

cc https://github.com/rust-lang/rust/issues/71249

This is an alternative to `@pnkfelix's` initial implementation in https://github.com/pnkfelix/rust/commits/prototype-rustc-side-of-report-future-incompat (mainly because I started working before seeing that branch :smile: ).

My approach outputs the entire original `Diagnostic`, in a way that is compatible with incremental compilation. This is not yet integrated with compiletest, but can be used manually by passing `-Z emit-future-incompat-report` to `rustc`.

Several changes are made to support this feature:
* The `librustc_session/lint` module is moved to a new crate `librustc_lint_defs` (name bikesheddable). This allows accessing lint definitions from `librustc_errors`.
* The `Lint` struct is extended with an `Option<FutureBreakage>`. When present, it indicates that we should display a lint in the future-compat report. `FutureBreakage` contains additional information that we may want to display in the report (currently, a `date` field indicating when the crate will stop compiling).
* A new variant `rustc_error::Level::Allow` is added. This is used when constructing a diagnostic for a future-breakage lint that is marked as allowed (via `#[allow]` or `--cap-lints`). This allows us to capture any future-breakage diagnostics in one place, while still discarding them before they are passed to the `Emitter`.
* `DiagnosticId::Lint` is extended with a `has_future_breakage` field, indicating whether or not the `Lint` has future breakage information (and should therefore show up in the report).
* `Session` is given access to the `LintStore` via a new `SessionLintStore` trait (since `librustc_session` cannot directly reference `LintStore` without a cyclic dependency). We use this to turn a string `DiagnosticId::Lint` back into a `Lint`, to retrieve the `FutureBreakage` data.

Currently, `FutureBreakage.date` is always set to `None`. However, this could potentially be interpreted by Cargo in the future.

I've enabled the future-breakage report for the `ARRAY_INTO_ITER` lint, which can be used to test out this PR. The intent is to use the field to allow Cargo to determine the date of future breakage (as described in [RFC 2834](https://github.com/rust-lang/rfcs/blob/master/text/2834-cargo-report-future-incompat.md)) without needing to parse the diagnostic itself.

cc `@pnkfelix`

1  2 
compiler/rustc_interface/src/passes.rs

index a1487aa0060d5fe08000d8863f2874928dd842b1,5340cd6406295526c4b04dee19f23d0171359615..072194e332a5b763252320c70e2968a8b7706595
@@@ -70,17 -70,6 +70,17 @@@ impl mut_visit::MutVisitor for TokenStr
          i.tokens = None;
          mut_visit::noop_flat_map_foreign_item(i, self)
      }
 +    fn flat_map_trait_item(
 +        &mut self,
 +        mut i: P<ast::AssocItem>,
 +    ) -> SmallVec<[P<ast::AssocItem>; 1]> {
 +        i.tokens = None;
 +        mut_visit::noop_flat_map_assoc_item(i, self)
 +    }
 +    fn flat_map_impl_item(&mut self, mut i: P<ast::AssocItem>) -> SmallVec<[P<ast::AssocItem>; 1]> {
 +        i.tokens = None;
 +        mut_visit::noop_flat_map_assoc_item(i, self)
 +    }
      fn visit_block(&mut self, b: &mut P<ast::Block>) {
          b.tokens = None;
          mut_visit::noop_visit_block(b, self);
@@@ -286,7 -275,10 +286,10 @@@ pub fn register_plugins<'a>
          }
      });
  
-     Ok((krate, Lrc::new(lint_store)))
+     let lint_store = Lrc::new(lint_store);
+     sess.init_lint_store(lint_store.clone());
+     Ok((krate, lint_store))
  }
  
  fn pre_expansion_lint(sess: &Session, lint_store: &LintStore, krate: &ast::Crate) {