Debuginfo revamp

[bleibig]

This is a rewrite of create_ty in debuginfo along with some other functions to modernize it with the current state of the language. The major change is that it no longer takes in an ast::Ty and instead only works with a ty::t, this is because ty::t seems to offer a more complete representation of the rust type system, and most types (like pointers and vecs) do not really need the span info that an ast::Ty provides.

What works right now are basic types, tuples and structs. Box, owning pointers, and vecs are not supported even though the code is there, apparently the implementation of these types changed since the debuginfo code was last updated. Also not yet implemented are strings, enums, traits, barefns, and closures, and will cause an ICE if you try to generate debuginfo for them.

This makes progress towards #2012 (or completes it, depending on the criteria).

[nikomatsakis]

nice to see progress in this area!

[jdm]

\o/

[bleibig]

The test failure was because different versions of gdb print structs differently, i.e. the old version (6.3) that ships on OS X prints a tuple like

$1 = {
  4,
  5.5,
  true
}

whereas a more recent version prints on one line like $1 = {4, 5.5, true}. The output checker (which is a rudimentary version of FileCheck) sees those two forms as different. I don't see an easy way to immediately fix this, so I'll just disable these checks for now.

[jdm]

That may be due to differences in gdb pretty-printing defaults. Does |set print pretty false| make a difference in the old gdb's output?

[bleibig]

The command is set print pretty off, but yes, that works on the old gdb and will print structs in the compact form.

[bleibig]

The test failure is due to gdb requiring administrator authentication on the mac build server. If that can somehow be fixed I bet the tests will finally pass and these changes can be landed.

[brson]

We can probably arrange for the bots to run with the correct privileges to run gdb, but developers will still end up running into this issue when running the test suite.

Is it ok to just not run debuginfo tests on OS X?

[bleibig]

I guess that will work, but maybe you can re-enable it with a configure flag. The test suite wiki page should also be updated with details as to why the tests are disabled by default and how to enable them. I found that the command DevToolsSecurity -enable puts you into developer mode and eliminates the authentication prompt when attaching gdb to another process.

[brson]

Continued at #5319