Rustup to rustc 1.16.0-nightly (24055d0f2 2017-01-31)

[Mrmaxmeier]

Relevant rustc changes:

• rename tcx.map to tcx.hir
• rename Tables to TypeckTables
• Merge ty::TyBox into ty::TyAdt
• rustc: move most of lifetime elision to resolve_lifetimes.

fixes #1475 and #1485

[oli-obk]

This should probably be TyRptr(ref lt, _) if lt.is_elided() =>

[oli-obk]

that's lt.is_elided()

[oli-obk]

this needs a !is_elided check on the lifetime.

[oli-obk]

@eddyb: do you have any hints as to how lifetime elision changed in the following snippet?

fn trait_obj_elided2<'a>(_arg: &'a Drop) -> &'a str { unimplemented!() }

[eddyb]

Whar are you talking about, there's no elision there.

[oli-obk]

right. That was badly formulated. The lifetimes represented by rustc have changed, but I can't figure out how your code changes would even affect this code snippet.

[eddyb]

Did something user-observed change, or just the compiler-internal representation?

If the latter, all lifetimes (in types) are explicit now.
So you have to check .is_elided() which returns false if the user wrote it.

[oli-obk]

@eddyb: just compiler-internal representation changes. if the &'a Drop is passed to an intravisit::Visitor via visit_ty, it will encounter an elided lifetime (in visit_lifetime), which it did not encounter before.

[eddyb]

Yeah, almost everything looking at a lifetime needs to ask .is_elided().

[Mrmaxmeier]

I'm not sure if its possible to distinguish between these two cases without more context:

fn trait_obj_elided<'a>(_arg: &'a WithLifetime) -> &'a str;
fn trait_obj_elided2<'a>(_arg: &'a Drop) -> &'a str;

Both args are essentially the same:

TyRptr(
    lifetime('a, not elided),
    TyTraitObject( PolyTraitRef( .. ), lifetime(elided) )
)

[oli-obk]

I'm not sure if its possible to distinguish between these two cases without more context:

we don't need to, we just need to ignore the TyTraitObject lifetime in case it is elided. I took the liberty of pushing the patch directly to this PR.

[mcarton]

@oli-obk Could you publish a git tag when you publish a new version?

[oli-obk]

I tried to, it didn't accept leaving the message empty, so I wanted to check what you usually wrote into it, then I forgot about it...

Do you think it would make sense to stop filling in the CHANGELOG, and instead use the tagging feature to fill in the same information but in a structured manner?

[mcarton]

Do you think it would make sense to stop filling in the CHANGELOG, and instead use the tagging feature to fill in the same information but in a structured manner?

Only signed tags need a message. I usually just write the version number.
I usually like to have a changelog that groups all versions in one document, because that makes it easy to find when something happened. It's also easy to add something in the changelog for an old version if we have forgotten something then. Tags are not that convenient.
But maybe we could just copy&paste the corresponding section from the changelog in the tag instead.