On 2014-03-14 18:22:19 +0000, Jacob Carlborg <doob@me.com> said:

> On 2014-03-14 13:09, Michel Fortin wrote:
> 
>> But before you can consider building such a tool, you'll have to
>> convince Walter that the locations of tokens should be tracked more
>> precisely in the frontend. Currently the frontend remembers only the
>> file and line of any token it finds. You can't implement a refactoring
>> with that. Last time that came in in a discussion (about error messages
>> showing the exact location of the error), the idea was shut down on the
>> ground that storing better location info would slow down the compiler.
> 
> This as already been implemented [1]. DMD (git master) now supports the -vcolumns flag to display error message with information about the column.
> 
> [1] https://github.com/D-Programming-Language/dmd/pull/3077

Makes me think, instead of generating patches or altering code, we could take the clang approach and simply suggest fixes during compilation. This is what suggested fixes looks like in clang:

page.mm:67:8: warning: using the result of an assignment as a condition without parentheses [-Wparentheses]
        if (x = 4)
            ~~^~~
page.mm:67:8: note: place parentheses around the assignment to silence this warning
        if (x = 4)
              ^
            (    )
page.mm:67:8: note: use '==' to turn this assignment into an equality comparison
        if (x = 4)
              ^
              ==

The two "note:" messages are the two possible suggested fixes.

If you're using Xcode, the IDE will actually parse those notes and let you choose between the two proposed fixes in a popup menu.
http://i.stack.imgur.com/UqIqm.png

-- 
Michel Fortin
michel.fortin@michelf.ca
http://michelf.ca

On 2014-03-14 20:26, Michel Fortin wrote:

> Makes me think, instead of generating patches or altering code, we could
> take the clang approach and simply suggest fixes during compilation.
> This is what suggested fixes looks like in clang:

I don't really think this is the same. It also adds a lot work since the isn't making the actual change.

-- 
/Jacob Carlborg

On 2014-03-14 21:36:56 +0000, Jacob Carlborg <doob@me.com> said:

> On 2014-03-14 20:26, Michel Fortin wrote:
> 
>> Makes me think, instead of generating patches or altering code, we could
>> take the clang approach and simply suggest fixes during compilation.
>> This is what suggested fixes looks like in clang:
> 
> I don't really think this is the same. It also adds a lot work since the isn't making the actual change.

It's giving you all the data needed to make the change.

If Xcode can parse this output and patch your code with one click in the editor, then you can also build a tool parsing the output and generating those patches automatically, as long as there's no ambiguity about the fix. Or if there's ambiguity, you could have an interactive command line tool ask how you want it patched.

The only difference is the UI around the compiler.

-- 
Michel Fortin
michel.fortin@michelf.ca
http://michelf.ca

On 2014-03-15 00:57, Michel Fortin wrote:

> It's giving you all the data needed to make the change.
>
> If Xcode can parse this output and patch your code with one click in the
> editor, then you can also build a tool parsing the output and generating
> those patches automatically, as long as there's no ambiguity about the
> fix. Or if there's ambiguity, you could have an interactive command line
> tool ask how you want it patched.

Fair enough.

-- 
/Jacob Carlborg