Lifetime Regression using Parser::parse_all_token_trees

[KyleMayes]

The below code worked until I updated today. I'm not sure which version of the nightly build I had previously, but it was about ten days old.

#![feature(rustc_private)]

extern crate syntax;

use syntax::parse;
use syntax::ast::{TokenTree};
use syntax::parse::{ParseSess};

fn parse_token_trees(source: &str) -> Vec<TokenTree> {
    let session = ParseSess::new();
    let source = source.into();
    let mut parser = parse::new_parser_from_source_str(&session, vec![], "".into(), source);
    parser.parse_all_token_trees().unwrap()
}

Rust Playpen (this produces the same error I am seeing)

If I change it to this, it compiles:

#![feature(rustc_private)]

extern crate syntax;

use syntax::parse;
use syntax::ast::{TokenTree};
use syntax::parse::{ParseSess};

fn parse_token_trees(source: &str) -> Vec<TokenTree> {
    let session = ParseSess::new();
    let source = source.into();
    let mut parser = parse::new_parser_from_source_str(&session, vec![], "".into(), source);
    let tts = parser.parse_all_token_trees().unwrap();
    tts
}

Meta

rustc 1.7.0-nightly (2370d461a 2015-12-30)
binary: rustc
commit-hash: 2370d461a648035b54aae492e7df66256f0f18c6
commit-date: 2015-12-30
host: x86_64-unknown-linux-gnu
release: 1.7.0-nightly

[arielb1]

The problem is that parse_all_token_trees now returns a Result<Vec<TokenTree>, DiagnosticBuilder<'sess>>, and DiagnosticBuilder<'sess> has a destructor (that even uses the borrowed data!) and therefore session must be alive for the containing scope, so from a compiler POV this is a simple case of API breakage.

On the other hand:

1. I think the lifetime restriction is unnecessary here - after all, the Result is always consumed by the unwrap, so it is never destroyed by the caller - so we could try to have dropck be smarter about this kind of thing, but that would be low-priority
2. We could use better error-reporting for lifetime conflicts - currently, we unpredictably pick 2 constraints that are related to the conflict, but we throw away all other constraints without looking at them.

[llogiq]

Probably related to #28970

[arielb1]

not a compiler bug, and the "unpredictably pick 2 constraints" part had been fixed in May.