Enrico Granata de61cecd1c <rdar://problem/15530080> ... Rework data formatters matching algorithm What happens now is that, for each category, the FormatNavigator generates all possible matches, and checks them one by one Since the possible matches do not actually depend on the category (whether a match is accepted or not does, but that check can be shifted at a more convenient time), it is actually feasible to generate every possible match upfront and then let individual categories just scan through those This commit changes things by introducing a notion of formatters match candidate, and shifting responsibility for generating all of them given a (ValueObject,DynamicValueType) pair from the FormatNavigator back to the FormatManager A list of these candidates is then passed down to each category for matching Candidates also need to remember whether they were generated by stripping pointers, references, typedefs, since this is something that individual formatters can choose to reject This check, however, is conveniently only done once a "textual" match has been found, so that the list of candidates is truly category-independent While the performance benefit is small (mostly, due to caching), this is much cleaner from a design perspective llvm-svn: 195395		2013-11-22 00:02:13 +00:00
..
lldb	<rdar://problem/15530080>	2013-11-22 00:02:13 +00:00
Makefile	Merged Eli Friedman's linux build changes where he added Makefile files that	2010-07-09 20:39:50 +00:00