www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Compiler updating user code

reply Manu <turkeyman gmail.com> writes:
So it comes up fairly regularly that people suggest that the compiler
should have a mode where it may update user code automatically to assist
migration to new compiler versions.

I'm personally against the idea, and Walter certainly doesn't like it, but
it occurred to me that a slight variation on this idea might be awesome.

Imagine instead, an '-update' option which instead of modifying your code,
would output a .patch file containing suggested amendments wherever it
encountered deprecated code...
The user can then take this patch file, inspect it visually using their
favourite merge tool, and pick and choose the bits that they agree or
disagree with.

I would say this approach takes a dubious feature and turns it into a
spectacular feature!

Language changes are probably easy enough to handle, but what about cases
of 'deprecated' in the library?
It's conceivable that the deprecated keyword could take an optional
argument to a CTFE function which would receive the expression as a string,
and the function could transform and return an amended string which would
also be added to the output patch file. This way, the feature could
conceivably also offer upgrade advice for arbitrary library changes.

Considering the advice in the context of a visual diff/merge window would
be awesome if you ask me.
Mar 13 2014
next sibling parent reply "Rikki Cattermole" <alphaglosined gmail.com> writes:
On Friday, 14 March 2014 at 05:15:05 UTC, Manu wrote:

 So it comes up fairly regularly that people suggest that the 
 compiler
 should have a mode where it may update user code automatically 
 to assist
 migration to new compiler versions.

 I'm personally against the idea, and Walter certainly doesn't 
 like it, but
 it occurred to me that a slight variation on this idea might be 
 awesome.

 Imagine instead, an '-update' option which instead of modifying 
 your code,
 would output a .patch file containing suggested amendments 
 wherever it
 encountered deprecated code...
 The user can then take this patch file, inspect it visually 
 using their
 favourite merge tool, and pick and choose the bits that they 
 agree or
 disagree with.

 I would say this approach takes a dubious feature and turns it 
 into a
 spectacular feature!

 Language changes are probably easy enough to handle, but what 
 about cases
 of 'deprecated' in the library?
 It's conceivable that the deprecated keyword could take an 
 optional
 argument to a CTFE function which would receive the expression 
 as a string,
 and the function could transform and return an amended string 
 which would
 also be added to the output patch file. This way, the feature 
 could
 conceivably also offer upgrade advice for arbitrary library 
 changes.

 Considering the advice in the context of a visual diff/merge 
 window would
 be awesome if you ask me.


Sounds like a cool idea. But not as part of the compiler. Its 
more of a use case for compiler as a library ;)
Mar 14 2014
next sibling parent "Sergei Nosov" <sergei.nosov gmail.com> writes:
On Friday, 14 March 2014 at 07:10:43 UTC, Rikki Cattermole wrote:

 On Friday, 14 March 2014 at 05:15:05 UTC, Manu wrote:

 So it comes up fairly regularly that people suggest that the 
 compiler
 should have a mode where it may update user code automatically 
 to assist
 migration to new compiler versions.

 I'm personally against the idea, and Walter certainly doesn't 
 like it, but
 it occurred to me that a slight variation on this idea might 
 be awesome.

 Imagine instead, an '-update' option which instead of 
 modifying your code,
 would output a .patch file containing suggested amendments 
 wherever it
 encountered deprecated code...
 The user can then take this patch file, inspect it visually 
 using their
 favourite merge tool, and pick and choose the bits that they 
 agree or
 disagree with.

 I would say this approach takes a dubious feature and turns it 
 into a
 spectacular feature!

 Language changes are probably easy enough to handle, but what 
 about cases
 of 'deprecated' in the library?
 It's conceivable that the deprecated keyword could take an 
 optional
 argument to a CTFE function which would receive the expression 
 as a string,
 and the function could transform and return an amended string 
 which would
 also be added to the output patch file. This way, the feature 
 could
 conceivably also offer upgrade advice for arbitrary library 
 changes.

 Considering the advice in the context of a visual diff/merge 
 window would
 be awesome if you ask me.


 Sounds like a cool idea. But not as part of the compiler. Its 
 more of a use case for compiler as a library ;)


I believe the first candidate is `dub fix` - by analogy with `go 
fix`. I also believe this kind of tool would be great for 
handling language changes. However, it seems implementing and 
maintaining it is quite a lot of work.
Mar 14 2014
prev sibling parent Xavier Bigand <flamaros.xavier gmail.com> writes:
Le 14/03/2014 08:10, Rikki Cattermole a écrit :

 On Friday, 14 March 2014 at 05:15:05 UTC, Manu wrote:

 So it comes up fairly regularly that people suggest that the compiler
 should have a mode where it may update user code automatically to assist
 migration to new compiler versions.

 I'm personally against the idea, and Walter certainly doesn't like it,
 but
 it occurred to me that a slight variation on this idea might be awesome.

 Imagine instead, an '-update' option which instead of modifying your
 code,
 would output a .patch file containing suggested amendments wherever it
 encountered deprecated code...
 The user can then take this patch file, inspect it visually using their
 favourite merge tool, and pick and choose the bits that they agree or
 disagree with.

 I would say this approach takes a dubious feature and turns it into a
 spectacular feature!

 Language changes are probably easy enough to handle, but what about cases
 of 'deprecated' in the library?
 It's conceivable that the deprecated keyword could take an optional
 argument to a CTFE function which would receive the expression as a
 string,
 and the function could transform and return an amended string which would
 also be added to the output patch file. This way, the feature could
 conceivably also offer upgrade advice for arbitrary library changes.

 Considering the advice in the context of a visual diff/merge window would
 be awesome if you ask me.


 Sounds like a cool idea. But not as part of the compiler. Its more of a
 use case for compiler as a library ;)


IMO these kind of tool is same as code beautifuler or refactoring 
helpers (eclipse give you some tips to fix your errors on imports,...)
Mar 14 2014
prev sibling next sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Manu" <turkeyman gmail.com> wrote in message 
news:mailman.105.1394774104.23258.digitalmars-d puremagic.com...


 So it comes up fairly regularly that people suggest that the compiler 
 should have a mode where it
 may update user code automatically to assist migration to new compiler 
 versions.

 I'm personally against the idea, and Walter certainly doesn't like it, but 
 it occurred to me that a
 slight variation on this idea might be awesome.

 Imagine instead, an '-update' option which instead of modifying your code, 
 would output a .patch
 file containing suggested amendments wherever it encountered deprecated 
 code...
 The user can then take this patch file, inspect it visually using their 
 favourite merge tool, and pick
 and choose the bits that they agree or disagree with.

 I would say this approach takes a dubious feature and turns it into a 
 spectacular feature!


If you're using version control, these are practically the same thing.  If 
not, you have bigger problems.


 Language changes are probably easy enough to handle, but what about cases 
 of 'deprecated' in
 the library?
 It's conceivable that the deprecated keyword could take an optional 
 argument to a CTFE function
 which would receive the expression as a string, and the function could 
 transform and return an
 amended string which would also be added to the output patch file. This 
 way, the feature could
 conceivably also offer upgrade advice for arbitrary library changes.

 Considering the advice in the context of a visual diff/merge window would 
 be awesome if you ask
 me.


Simple updates could be trivially scripted, but more complex ones would need 
full re-write rules.  All of this is fairly easy to do, and is a simple form 
of auto-refactoring code.

Once we have a full-featured auto-formatter we'll be most of the way there.
Mar 14 2014
parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Friday, 14 March 2014 at 11:44:21 UTC, Daniel Murphy wrote:

 "Manu" <turkeyman gmail.com> wrote in message 
 news:mailman.105.1394774104.23258.digitalmars-d puremagic.com...


 So it comes up fairly regularly that people suggest that the 
 compiler should have a mode where it
 may update user code automatically to assist migration to new 
 compiler versions.

 I'm personally against the idea, and Walter certainly doesn't 
 like it, but it occurred to me that a
 slight variation on this idea might be awesome.

 Imagine instead, an '-update' option which instead of 
 modifying your code, would output a .patch
 file containing suggested amendments wherever it encountered 
 deprecated code...
 The user can then take this patch file, inspect it visually 
 using their favourite merge tool, and pick
 and choose the bits that they agree or disagree with.

 I would say this approach takes a dubious feature and turns it 
 into a spectacular feature!


 If you're using version control, these are practically the same 
 thing.


Yeah, I don't understand why it matters whether it's a change or 
a patch. Either way, all changes become patches in VCS. Who would 
let an automated tool make source changes without using VC, or at 
least having made a manual backup?

Also, making a direct change allows the user to use whatever diff 
software / version control software they like.
Mar 14 2014
next sibling parent reply Manu <turkeyman gmail.com> writes:
On 14 March 2014 22:07, John Colvin <john.loughran.colvin gmail.com> wrote:


 On Friday, 14 March 2014 at 11:44:21 UTC, Daniel Murphy wrote:


 "Manu" <turkeyman gmail.com> wrote in message
 news:mailman.105.1394774104.23258.digitalmars-d puremagic.com...

  So it comes up fairly regularly that people suggest that the compiler

 should have a mode where it
 may update user code automatically to assist migration to new compiler
 versions.

 I'm personally against the idea, and Walter certainly doesn't like it,
 but it occurred to me that a
 slight variation on this idea might be awesome.

 Imagine instead, an '-update' option which instead of modifying your
 code, would output a .patch
 file containing suggested amendments wherever it encountered deprecated
 code...
 The user can then take this patch file, inspect it visually using their
 favourite merge tool, and pick
 and choose the bits that they agree or disagree with.

 I would say this approach takes a dubious feature and turns it into a
 spectacular feature!


 If you're using version control, these are practically the same thing.


 Yeah, I don't understand why it matters whether it's a change or a patch.
 Either way, all changes become patches in VCS. Who would let an automated
 tool make source changes without using VC, or at least having made a manual
 backup?


Because Walter is acutely allergic to the idea of a tool that modifies your
source code. I might also have uncommitted changes, and not particularly
feel like stashing them for the moment (less easy in other VCS's).
I might also not want to apply all the changes, only some of them. Surely
it's easier to merge the ones I want after visual approval, than reverting
the ones I don't want after having gone to the effort of stashing my local
changes to make a clean slate to work with...

Also, making a direct change allows the user to use whatever diff software

 / version control software they like.


I'm not sure how a patch file restricts them to a particular merge program
or VCS...
Mar 14 2014
next sibling parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Friday, 14 March 2014 at 12:23:01 UTC, Manu wrote:

 On 14 March 2014 22:07, John Colvin 
 <john.loughran.colvin gmail.com> wrote:


 On Friday, 14 March 2014 at 11:44:21 UTC, Daniel Murphy wrote:


 "Manu" <turkeyman gmail.com> wrote in message
 news:mailman.105.1394774104.23258.digitalmars-d puremagic.com...

  So it comes up fairly regularly that people suggest that the 
 compiler

 should have a mode where it
 may update user code automatically to assist migration to 
 new compiler
 versions.

 I'm personally against the idea, and Walter certainly 
 doesn't like it,
 but it occurred to me that a
 slight variation on this idea might be awesome.

 Imagine instead, an '-update' option which instead of 
 modifying your
 code, would output a .patch
 file containing suggested amendments wherever it encountered 
 deprecated
 code...
 The user can then take this patch file, inspect it visually 
 using their
 favourite merge tool, and pick
 and choose the bits that they agree or disagree with.

 I would say this approach takes a dubious feature and turns 
 it into a
 spectacular feature!


 If you're using version control, these are practically the 
 same thing.


 Yeah, I don't understand why it matters whether it's a change 
 or a patch.
 Either way, all changes become patches in VCS. Who would let 
 an automated
 tool make source changes without using VC, or at least having 
 made a manual
 backup?


 Because Walter is acutely allergic to the idea of a tool that 
 modifies your
 source code. I might also have uncommitted changes, and not 
 particularly
 feel like stashing them for the moment (less easy in other 
 VCS's).
 I might also not want to apply all the changes, only some of 
 them. Surely
 it's easier to merge the ones I want after visual approval, 
 than reverting
 the ones I don't want after having gone to the effort of 
 stashing my local
 changes to make a clean slate to work with...


I appreciate it would be convenient, but changing compiler 
versions and patching up the code is a major enough update to 
justify a branch IMO, let alone just a commit or stash.

Anyway, I don't think it matters that much either way.

Admittedly my experience is limited to git and mercurial, both of 
which deal with these sorts of situations trivially.


 Also, making a direct change allows the user to use whatever 
 diff software

 / version control software they like.


 I'm not sure how a patch file restricts them to a particular 
 merge program
 or VCS...


I suppose not. I was assuming that there might be different 
standards for patch files.
Mar 14 2014
parent Manu <turkeyman gmail.com> writes:
On 14 March 2014 22:31, John Colvin <john.loughran.colvin gmail.com> wrote:

 I appreciate it would be convenient, but changing compiler versions and
 patching up the code is a major enough update to justify a branch IMO, let
 alone just a commit or stash.

 Anyway, I don't think it matters that much either way.

 Admittedly my experience is limited to git and mercurial, both of which
 deal with these sorts of situations trivially.


You may be right. I just thought of it as a solution to a suggestion that
comes up frequently, but is considered obnoxious by some people.
DMD is no stranger out outputting files beside the compilation output, like
the .json file for instance. I would personally find the patch approach
convenient, and it could subvert some other issues, like what if there is
no write access to the source tree?
Mar 14 2014
prev sibling parent "Dicebot" <public dicebot.lv> writes:
On Friday, 14 March 2014 at 12:23:01 UTC, Manu wrote:

 Because Walter is acutely allergic to the idea of a tool that 
 modifies your
 source code. I might also have uncommitted changes, and not 
 particularly
 feel like stashing them for the moment (less easy in other 
 VCS's).
 I might also not want to apply all the changes, only some of 
 them. Surely
 it's easier to merge the ones I want after visual approval, 
 than reverting
 the ones I don't want after having gone to the effort of 
 stashing my local
 changes to make a clean slate to work with...


It is a problem with your VCS workflow, not the imaginary tool. 
Having any sort of uncommitted changes other than during active 
editing goes against idea of DVCS.
Mar 14 2014
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Mar 14, 2014 at 12:07:24PM +0000, John Colvin wrote:

 On Friday, 14 March 2014 at 11:44:21 UTC, Daniel Murphy wrote:

"Manu" <turkeyman gmail.com> wrote in message
news:mailman.105.1394774104.23258.digitalmars-d puremagic.com...


So it comes up fairly regularly that people suggest that the
compiler should have a mode where it may update user code
automatically to assist migration to new compiler versions.

I'm personally against the idea, and Walter certainly doesn't like
it, but it occurred to me that a slight variation on this idea might
be awesome.

Imagine instead, an '-update' option which instead of modifying your
code, would output a .patch file containing suggested amendments
wherever it encountered deprecated code...  The user can then take
this patch file, inspect it visually using their favourite merge
tool, and pick and choose the bits that they agree or disagree with.

I would say this approach takes a dubious feature and turns it
into a spectacular feature!


If you're using version control, these are practically the same
thing.


 
 Yeah, I don't understand why it matters whether it's a change or a
 patch. Either way, all changes become patches in VCS. Who would let
 an automated tool make source changes without using VC, or at least
 having made a manual backup?


I believe the point is to let the user *selectively* apply the diffs.
A VCS doesn't help you in that area -- you either apply the entire set
of changes, or nothing at all (at least within a single file).


T

-- 
Two wrongs don't make a right; but three rights do make a left...
Mar 14 2014
parent "Dicebot" <public dicebot.lv> writes:
On Friday, 14 March 2014 at 14:39:37 UTC, H. S. Teoh wrote:

 I believe the point is to let the user *selectively* apply the 
 diffs.
 A VCS doesn't help you in that area -- you either apply the 
 entire set
 of changes, or nothing at all (at least within a single file).


 T


This is not true. git allows you to add separate changes from a 
single file into different change sets (git add -i)
Mar 14 2014
prev sibling next sibling parent reply Michel Fortin <michel.fortin michelf.ca> writes:
On 2014-03-14 05:14:52 +0000, Manu <turkeyman gmail.com> said:


 So it comes up fairly regularly that people suggest that the compiler
 should have a mode where it may update user code automatically to assist
 migration to new compiler versions.
 
 I'm personally against the idea, and Walter certainly doesn't like it, but
 it occurred to me that a slight variation on this idea might be awesome.
 
 Imagine instead, an '-update' option which instead of modifying your code,
 would output a .patch file containing suggested amendments wherever it
 encountered deprecated code...
 The user can then take this patch file, inspect it visually using their
 favourite merge tool, and pick and choose the bits that they agree or
 disagree with.
 
 I would say this approach takes a dubious feature and turns it into a
 spectacular feature!


If you're using a version control system, it's probably simpler to just 
apply the patch automatically and then review it like you'd review any 
change you're ready to commit, while tweaking the changes if needed.

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.



 Language changes are probably easy enough to handle, but what about cases
 of 'deprecated' in the library?
 It's conceivable that the deprecated keyword could take an optional
 argument to a CTFE function which would receive the expression as a string,
 and the function could transform and return an amended string which would
 also be added to the output patch file. This way, the feature could
 conceivably also offer upgrade advice for arbitrary library changes.
 
 Considering the advice in the context of a visual diff/merge window would
 be awesome if you ask me.


Xcode has a refactoring for transitioning to ARC, and it works by 
presenting you a merge view of the changes, which you can edit, before 
saving them. I'm sure other IDEs can do that too.
http://cdn5.raywenderlich.com/wp-content/uploads/2012/01/Review-Changes.png

-- 
Michel Fortin
michel.fortin michelf.ca
http://michelf.ca
Mar 14 2014
next sibling parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Michel Fortin"  wrote in message news:lfurh8$qae$1 digitalmars.com... 


 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.


Yeah, we'll have to do this at some point.
Mar 14 2014
prev sibling next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 3/14/14, Michel Fortin <michel.fortin michelf.ca> 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.


Note that if this tool is built-in to the compiler (as a feature) it
will have some big drawbacks:

1) It's only released when the compiler is released. If the feature
has regressions you are tied to the DMD release schedule before you
can release a fix.

2) The feature will only work with the latest compiler. In other
words, if you want to update a 2.070 codebase to 2.072, you will
actually need to use two compilers. The porting tool released with DMD
2.071 to port 2.070 to 2.071, and the tool released with 2.072 to port
2.071 to 2.072.

What I mean is, the parser in DMD v2.072 might not be able to parse
code written for v2.070. But if the conversion tool was separate from
both the compiler and its internal parser then you could make the tool
work for an entire range of codebase versions, and e.g. directly port
a v2.070 codebase to 2.080.

You could even back-port code. Let's say you've started using 2.070
for over a month, and you hit a major performance regression. You're
short on time, you need to release your app to the public
(deadlines..), but you have to wait for the fix. With the tool you
could potentially be able to port the code back to 2.069 which didn't
have the performance regression.

This is all theoretical so far.

Anyway if someone wants to build it in the compiler, I won't stop them.
Mar 14 2014
parent Michel Fortin <michel.fortin michelf.ca> writes:
On 2014-03-14 12:46:33 +0000, Andrej Mitrovic 
<andrej.mitrovich gmail.com> said:


 2) The feature will only work with the latest compiler. In other
 words, if you want to update a 2.070 codebase to 2.072, you will
 actually need to use two compilers. The porting tool released with DMD
 2.071 to port 2.070 to 2.071, and the tool released with 2.072 to port
 2.071 to 2.072.


I see what you mean. The moment the parser can't recognize the old 
thing, you can't migrate.

But it doesn't have to be as you say. You can keep things working in a 
deprecated state for longer than one version. As long as the old thing 
can be parsed, it can be updated.

-- 
Michel Fortin
michel.fortin michelf.ca
http://michelf.ca
Mar 14 2014
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
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

-- 
/Jacob Carlborg
Mar 14 2014
next sibling parent Michel Fortin <michel.fortin michelf.ca> writes:
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


Oh, I missed that. Great!

I'm still not entirely sure it retains enough information to perform a 
refactoring, but it's a start.

-- s
Michel Fortin
michel.fortin michelf.ca
http://michelf.ca
Mar 14 2014
prev sibling parent reply Michel Fortin <michel.fortin michelf.ca> writes:
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
Mar 14 2014
parent reply Jacob Carlborg <doob me.com> writes:
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
Mar 14 2014
parent reply Michel Fortin <michel.fortin michelf.ca> writes:
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
Mar 14 2014
parent Jacob Carlborg <doob me.com> writes:
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
Mar 15 2014
prev sibling parent reply "Frustrated" <Frustrated nowhere.com> writes:
On Friday, 14 March 2014 at 05:15:05 UTC, Manu wrote:

 So it comes up fairly regularly that people suggest that the 
 compiler
 should have a mode where it may update user code automatically 
 to assist
 migration to new compiler versions.

 I'm personally against the idea, and Walter certainly doesn't 
 like it, but
 it occurred to me that a slight variation on this idea might be 
 awesome.

 Imagine instead, an '-update' option which instead of modifying 
 your code,
 would output a .patch file containing suggested amendments 
 wherever it
 encountered deprecated code...
 The user can then take this patch file, inspect it visually 
 using their
 favourite merge tool, and pick and choose the bits that they 
 agree or
 disagree with.

 I would say this approach takes a dubious feature and turns it 
 into a
 spectacular feature!

 Language changes are probably easy enough to handle, but what 
 about cases
 of 'deprecated' in the library?
 It's conceivable that the deprecated keyword could take an 
 optional
 argument to a CTFE function which would receive the expression 
 as a string,
 and the function could transform and return an amended string 
 which would
 also be added to the output patch file. This way, the feature 
 could
 conceivably also offer upgrade advice for arbitrary library 
 changes.

 Considering the advice in the context of a visual diff/merge 
 window would
 be awesome if you ask me.


How difficult would it be to be able to configure the compiler 
for various updates directly?

What I mean is that suppose a few fixes were made and some 
breaking changes were made.

Could the compiler itself be configured in such a way(at least 
for most "breaking changes") that the user could switch the 
change on and off yet keep the fixes.

Example:

Suppose final by default and several bug fixes are added to 
version X + 1. If the user could configure the compiler so that 
he could simply keep the fixes but not have final by default(a 
sort of version x + 0.5) then he would get the benefit of the 
fixes without the breaking change.

I think it would probably be a maintenance nightmare and be 
extremely hard to implement because it is not easy to keep 
changes.

There are a few ways to think about it though. If the compiler 
kept every version it had in it's binary and the user could do 
-version2.063, for example, it would be easy to select the 
version. One can already download the version one wants so this 
isn't really a great solution.

But what is the differential between most versions? Just fixes 
and breaking changes. So is the compiler kept fixes and 
changes(sort of patches) in the binary that it could apply to 
itself and a dependency list is created it might be easier to 
manage.

Possibly with the proper software and methodologies it could be 
done. It would, at least, solve the problem. If someone didn't 
want some breaking change they simply could remove it from the 
compiler: -removechange1435 (maybe change 1435 is final by 
default) which reverts the compiler back to before that change 
BUT keeps all the fixes up to the current version that are not 
dependent on that change.


Another concept,

In windows, for example, you can install updates that "fix" 
problems. Most of the time you can roll back the changes.

Suppose one can do the same with the compiler. Instead of 
downloading a new version of a compiler one simply downloads the 
"fixes" and "changes". If a change is added that one doesn't like 
they just uninstall it.

This too would be difficult in some ways since compilers are 
generally not designed in such modular ways but it might be 
possible. (I guess essentially including the source code in the 
compiler and giving the compiler the ability to compile itself 
with the patches would be a way to achieve this)
Mar 14 2014
parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Frustrated"  wrote in message news:qkldntailmybifzsnwzn forum.dlang.org...


 Could the compiler itself be configured in such a way(at least for most 
 "breaking changes") that the user could switch the change on and off yet 
 keep the fixes.


It already is, breaking changes are first introduced as warnings, then as 
deprecations, then as errors.  While in the first two stages you can switch 
them on and off.


 Possibly with the proper software and methodologies it could be done. It 
 would, at least, solve the problem. If someone didn't want some breaking 
 change they simply could remove it from the compiler: -removechange1435 
 (maybe change 1435 is final by default) which reverts the compiler back to 
 before that change BUT keeps all the fixes up to the current version that 
 are not dependent on that change.


Way too hard.  Not gonna happen.


 Suppose one can do the same with the compiler. Instead of downloading a 
 new version of a compiler one simply downloads the "fixes" and "changes". 
 If a change is added that one doesn't like they just uninstall it.


Also way too hard.  The current way works fine.
Mar 14 2014