[cfe-commits] [Patch] Add highlighting and type eliding when two templates are used in a diagnostics. Also, template tree printing.

[Chandler Carruth]

On Wed, Feb 22, 2012 at 11:44 AM, Richard Trieu <rtrieu at google.com> wrote:

> On Mon, Feb 13, 2012 at 1:52 PM, Richard Trieu <rtrieu at google.com> wrote:
>
>> On Mon, Jan 30, 2012 at 10:41 AM, Richard Trieu <rtrieu at google.com>wrote:
>>
>>> On Wed, Jan 18, 2012 at 12:01 PM, Richard Trieu <rtrieu at google.com>wrote:
>>>
>>>> On Wed, Jan 11, 2012 at 6:22 PM, Richard Trieu <rtrieu at google.com>wrote:
>>>>
>>>>> On Tue, Dec 13, 2011 at 2:32 PM, Chandler Carruth <
>>>>> chandlerc at google.com> wrote:
>>>>>
>>>>>> I've left detailed comments on the codereview. Some of them might be
>>>>>> addressed by some of my high-level comments:
>>>>>>
>>>>>> How the various pieces of this interact are not clear from an initial
>>>>>> reading. I think we need lots of comments to clearly document how the
>>>>>> QualType's move into the ASTDiagnostics layer, and what the expect result
>>>>>> is when we are rendering strings in that layer, and how those results are
>>>>>> re-composed into the final diagnostic. Without that context at each layer,
>>>>>> it's hard to understand how this works.
>>>>>>
>>>>>> I lot of that has been cleaned up.  Comments have been added to
>>>>> document how the types are loaded.  Magic values have been moved to shared
>>>>> headers.
>>>>>
>>>>>>
>>>>>> The implementation of the new text is also quite hard to understand
>>>>>> for me. I have a theory as to why: There are really two orthogonal things
>>>>>> going on: one is computing the different (pruned) tree to print, and the
>>>>>> second is rendering the various parts of that tree to text. I think it
>>>>>> would help te separate these two as much as possible. What I'm envisioning
>>>>>> is first building an object which represents (in some tree-like
>>>>>> data-structure with a reasonable set of APIs) the "interesting" pieces of
>>>>>> the type(s). Then, methods on the object which (recursively) build a
>>>>>> textual representation out of it. Among other readability advantages this
>>>>>> would especially help by potentially factoring the two different styles of
>>>>>> formatting (tree vs. elision) more firmly -- they could be a largely
>>>>>> distinct collection of methods.
>>>>>>
>>>>>> The diffing has been separated into two phases.  The first phase
>>>>> walks the type and builds up a diff tree.  The second phase takes this diff
>>>>> tree and converts it into the output string.
>>>>>
>>>>>
>>>>>> As part of this (and as I mention in my detailed comments) it would
>>>>>> be good to move to a stream-based rendering system to make the composition
>>>>>> of the text easier to read as well as much more efficient.
>>>>>>
>>>>>> Moved from strings to a steam-based system.
>>>>>
>>>>>>
>>>>>> Finally, I think you'll need Doug to look at the actual logic of
>>>>>> computing the "interesting" set of nodes. I think that's going to be one of
>>>>>> the more tricky parts of this to get right.
>>>>>>
>>>>>
>>>>> Major changes from the last patch is the separation of the building of
>>>>> the diff information tree and the eventual construction of the output
>>>>> string.  Elision is handled a bit more consistently.  Also fixed a place
>>>>> where the two types get switched.
>>>>>
>>>>
>>>> Ping.
>>>>
>>> Ping.
>>
>> Ping.
>
> Ping.


:: hangs head in shame :: 4 pings in a row... bumping this up toward the
top.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120222/60232427/attachment.html>