Simplify utils::match_def_path, removing a FIXME

[llogiq]

changelog: none

This removes the Vec<Symbol> allocation. We still need to call cx.get_def_path, but this should already have been interned, and I don't see how we can keep ergonomics of that function without allocating a Vec.

r? @phansch

[oli-obk]

We can actually start getting rid of these string paths. The compiler now has support for diagnostic items. Look at the Debug trait to see how to change libcore to have more diag items

[phansch]

See Oli's comment :)

cc rust-lang/rust#60966

[llogiq]

I see how declaring diagnostic items will help, but that refactoring will be a larger one. This PR can still be useful in the meantime.

[phansch]

Oh, I thought it could have been a more granular change. Let's get this merged for now

@bors r+

[bors]

📌 Commit 72058a6 has been approved by phansch

[bors]

⌛ Testing commit 72058a6 with merge f30bf69...

[llogiq]

@oli-obk: So do we go through utils/paths.rs, find all the types, methods, etc. and set up Rust PRs with the rustc_diagnostic_item annotations? Also on the Rust side I see a lot of entries in sym, but only one rustc_diagnostic_item annotation on Debug. How do we ensure there's no name clash?

[bors]

☀️ Test successful - checks-travis, status-appveyor
Approved by: phansch
Pushing f30bf69 to master...

[oli-obk]

The entries in sym are entirely independent of the names we can use for diagnostic items. If there's already an entry in sym, don't add a new one. Just invent any name you think fits for the item. If it doesn't exist in sym yet, that's fine, either add it or let clippy generate the symbol from a string. I think we could go with not adding anything to the sym list for now

[llogiq]

OK, how do I find out what an item in sym points to?

[oli-obk]

You don't. The sym list has nothing to do with items. It's just interned names. Ignore the sym list. It's just a perf improvement, not a necessity

[llogiq]

I see. I tried this for Vec (will push WIP soon), but the tests failed.