<html>
 <body>
  <div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
   <table bgcolor="#f9f3c9" width="100%" cellpadding="8" style="border: 1px #c9c399 solid;">
    <tr>
     <td>
      This is an automatically generated e-mail. To reply, visit:
      <a href="http://git.reviewboard.kde.org/r/104930/">http://git.reviewboard.kde.org/r/104930/</a>
     </td>
    </tr>
   </table>
   <br />





 <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">I don't like the "language features" title too much, I think it's too vague and confusable. Wouldn't it be better to call it "language version"? Then, this could be added more generally into the framework, as it's useful for most languages. For example python will need it to distinguish between python-2 and python-3. I know that C is not an older version of C++, but this is how we model it in our language support.

Also, setting a project-global flag is not really scalable. For example, a project may contain both C and C++ code if it has some library copied into some sub-folder.

Therefore, I think the project-controller should be asked for the language, maybe like this: "QString version = projectController->languageVersionForUrl( url, ILanguage* language )". ILanguage again could supply a list of language-versions, which the project-manager would need to show somewhere in the UI to let the user pick, or could guess automatically.</pre>
 <br />







<p>- David</p>


<br />
<p>On May 13th, 2012, 6:41 a.m., Alexandre Courbot wrote:</p>






<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" style="background-image: url('http://git.reviewboard.kde.org/media/rb/images/review_request_box_top_bg.png'); background-position: left top; background-repeat: repeat-x; border: 1px black solid;">
 <tr>
  <td>

<div>Review request for KDevelop.</div>
<div>By Alexandre Courbot.</div>


<p style="color: grey;"><i>Updated May 13, 2012, 6:41 a.m.</i></p>






<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
 <table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
 <tr>
  <td>
   <pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">   Currently the parser is a pure C++ parser with C++11 elements, without
    any option to disable C++11 or to make it more C compatible. C
    compatibility in particular is a big challenge since many C++ tokens can
    be used as identifiers in C, and C also has some constructs that are not
    valid in C++ (like designated initializers or casted braced init lists).
    
    This patch adds "language features" which are flags that enable specific
    language support in the parser. Currently flags exist for C99, C++ and
    C++11. Code that invokes the parser can use the new
    setLanguageFeatures() method to change the current set of supported
    features (the default is C++ | C++11). This is useful for instance for
    C-specific projects.
    
    CppLanguageSupport::createParseJob has been modified to check for a
    "Language" entry in the configuration of the project the parsed file
    belongs to. Project controllers can set this option if they know that
    the project is limited to C, C++ or C++11 files. Other means (for
    instance, based on file extension of Makefile analysis) could be
    implemented in the future.
</pre>
  </td>
 </tr>
</table>


<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Testing </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
 <tr>
  <td>
   <pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Modified kdev-kernel to set that "Language=C" option to the projects it manages. Checked that C++ keywords like "class", "private" were indeed treated as identifiers. This alone improves kernel parsing quality a great deal.

Made sure that parsing of C++ projects is not affected in any way by this patch.</pre>
  </td>
 </tr>
</table>




<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">

 <li>languages/cpp/cpplanguagesupport.cpp <span style="color: grey">(4ee1ffe)</span></li>

 <li>languages/cpp/cppparsejob.h <span style="color: grey">(debb1b0)</span></li>

 <li>languages/cpp/cppparsejob.cpp <span style="color: grey">(1e0a51b)</span></li>

 <li>languages/cpp/parser/languagefeatures.h <span style="color: grey">(PRE-CREATION)</span></li>

 <li>languages/cpp/parser/lexer.h <span style="color: grey">(3494cbd)</span></li>

 <li>languages/cpp/parser/lexer.cpp <span style="color: grey">(81302d7)</span></li>

 <li>languages/cpp/parser/parser.h <span style="color: grey">(c519891)</span></li>

 <li>languages/cpp/parser/parser.cpp <span style="color: grey">(edeab85)</span></li>

 <li>languages/cpp/parser/tests/test_parser.h <span style="color: grey">(dea9902)</span></li>

 <li>languages/cpp/parser/tests/test_parser.cpp <span style="color: grey">(804f379)</span></li>

 <li>languages/cpp/preprocessjob.cpp <span style="color: grey">(803c237)</span></li>

</ul>

<p><a href="http://git.reviewboard.kde.org/r/104930/diff/" style="margin-left: 3em;">View Diff</a></p>




  </td>
 </tr>
</table>








  </div>
 </body>
</html>