An open question is whether we want to redefine Type.toString to preserve the old behaviour. I think we do ... but I'm going to let the tests run on this pull request first and see what it looks like if we don't...

As queries aren't supposed to depend on the behavior of toString this is really up to us:

Compilation of the query and any associated libraries and tests must be resilient to future development of the supported libraries. This means that the functionality [...] cannot make use of regexp matching on toString.

(from CONTRIBUTING.)

Yep, so it comes down to whether query output looks better with the full or short type names.

There are surprisingly few failing tests (no query tests, just a few integration tests), with differences like these:

-| Builtin.BridgeObject | BuiltinBridgeObjectType |
+| BridgeObject | BuiltinBridgeObjectType |

-| Builtin.Executor | BuiltinExecutorType |
+| Executor | BuiltinExecutorType |

-| T.Type | MetatypeType | T |
+| Type | MetatypeType | T |

I think the full names were clearer in these cases, so I'll switch Type.toString() to use that (i.e. preserve the old toString behaviour).

This also adds a fair number of new string operations to many pipelines so I think we should run DCA once we're happy with the output.

DCA LGTM (analysis time unaffected; stage timings OK as far as I can tell).

There are some test failures I need to fix though...

Test failures fixed - but I had to rewrite getName() to do it, now using a regex solution. This is because we have a wider variety of type names including dots than I had anticipated, such as tuple types (Int, A.B.C), and variadic sequence types A....

In a couple of places we were using getName() when we should have been using getFullName() but it didn't show up as a problem until now. This is now fixed as well.

I will do another DCA run after the tests pass, as the solution has fundamentally changed.

DCA still LGTM. It's slightly less clear than last time (analysis time has gone up but not by enough I'm sure it's a real effect) so I'll do a couple of local tests tomorrow to confirm.

Tested:

swift/path-injection on DanielZSY__RxCommonKit (inspired by one of the stage timing regressions)
	main: 89s, 79s
	PR: 107s, 93s

from Type t select t, t.getName() on DanielZSY__RxCommonKit
	main: 10s, 7s
	PR: 18s, 15s

from Type t select t, t.getName() on KrauseFx__MajorKey (the most slowed down analysis on the DCA run)
	main: 7s, 7s
	PR: 8s, 8s

I'll see if I can make this better...

Note that all this regex stuff may break in the future since we're fundamentally trying to parse the output of a function that's used for diagnostics only: https://github.com/apple/swift/blob/c2fc7ee9e72e9a39854548e3202c667e4934dc65/include/swift/AST/Types.h#L1429. Are we sure this is the direction we want to go in?

We use type names to match things like MAD models against things in the database - I think it's safe to say that if the underlying strings change, we will have to fix it somewhere.

We use type names to match things like MAD models against things in the database - I think it's safe to say that if the underlying strings change, we will have to fix it somewhere.

Yeah, but I'm wondering if the proper fix may be to change the extractor not not output this diagnostics name in the first place.

I'm wondering if the proper fix may be to change the extractor not not output this diagnostics name in the first place.

If there's a formal short name available, yes that would be fantastic! (and I believe we already do that for decls and perhaps other things)