<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body bgcolor="#FFFFFF" text="#000000">
The case was made that it is absolutely necessary to retain the
release branches in order to simplify preparation for point
releases. And, while I initially argued against it, I do not see how
it is possible to create the point release without doing so. However
I strongly believe that resolutions to these regressions should
first be implemented the oldest supported version (currently
2.065.1) and then merged forward to master. My reasoning? Read on!<br>
<br>
I conducted a search on bugzilla for all regressions RESOLVED as
FIXED after 2014-02-23 using the following:<br>
<br>
<a class="moz-txt-link-freetext" href="http://d.puremagic.com/issues/buglist.cgi?bug_severity=regression&bug_status=RESOLVED&chfield=resolution&chfieldfrom=2014-02-23&chfieldto=Now&chfieldvalue=FIXED&columnlist=changeddate%2Cbug_severity%2Cpriority%2Cop_sys%2Cassigned_to_realname%2Cbug_status%2Cresolution%2Cshort_desc&query_format=advanced&resolution=FIXED&order=changeddate%2Cresolution%2Cassigned_to%2Cbug_id&query_based_on=">http://d.puremagic.com/issues/buglist.cgi?bug_severity=regression&bug_status=RESOLVED&chfield=resolution&chfieldfrom=2014-02-23&chfieldto=Now&chfieldvalue=FIXED&columnlist=changeddate%2Cbug_severity%2Cpriority%2Cop_sys%2Cassigned_to_realname%2Cbug_status%2Cresolution%2Cshort_desc&query_format=advanced&resolution=FIXED&order=changeddate%2Cresolution%2Cassigned_to%2Cbug_id&query_based_on=</a><br>
<br>
I figured I'd cherry-pick each into the 2.065 branch (starting the
the oldest) as long as they were marked as regressions to v2.065.0
or older. Note that this approach does not correctly identify all
regressions that needs to be included in a point release (see issue
#12264 which is also fixes #12262). Anyway, I commenced by checking
out the branch and issuing the command:<br>
<br>
git cherry-pick -m 1 53bec85<br>
<br>
This specific pick is the merger of pull request #3339 which
resolves (Issue 12243 - "ICE: cannot append 'char' to 'string'" with
-inline). Immediately I encountered a merge conflict so I
investigated the resolution and came across the following:<br>
<br>
The pull essentially changes lines 1420 through 1425 of src/inline.c
[a part of visitCallExp(CallExp*, Expression*) implementation] <br>
<br>
From ----------><br>
<br>
if (eresult && e->type->ty != Tvoid &&<br>
!e->type->equals(eresult->type) &&<br>
eresult->type->hasWild() &&
!e->type->hasWild())<br>
{<br>
eresult = eresult->copy();<br>
eresult->type = e->type;<br>
}<br>
<br>
To ----------><br>
<br>
if (eresult && e->type->ty != Tvoid)<br>
{<br>
Expression *ex = eresult;<br>
while (ex->op == TOKcomma)<br>
{<br>
ex->type = e->type;<br>
ex = ((CommaExp *)ex)->e2;<br>
}<br>
ex->type = e->type;<br>
}<br>
<br>
So far so good. Now cross-reference this to the version of
src/inline.c from v2.065.0 and you will find that the function
visitCallExp() does not exist. Further the function resident at the
same location in the older version of the file [Expression *
SliceExp::inlineScan(InlineScanState *iss){}] does not exist
anywhere in the newer version (neither is any of a number of
inlineScan() related implementations surrounding it). As such, it is
not possible to pick this fix in preparation for v2.065.1.<br>
<br>
What is the proper resolution for this problem in the context of the
2.065 branch?<br>
<br>
<br>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
</body>
</html>