Review Request 121777: Make it possible to change language standard for the parser

Sergey Kalinichev kalinichev.so.0 at gmail.com
Thu Jan 8 11:11:24 UTC 2015



> On Jan. 7, 2015, 5:55 p.m., Milian Wolff wrote:
> > languages/plugins/custom-definesandincludes/compilerprovider/gcclikecompiler.cpp, line 56
> > <https://git.reviewboard.kde.org/r/121777/diff/2/?file=338580#file338580line56>
> >
> >     I suggest adding a compilerStandards function here, which creates the _QHash_ statically internally and returns that.

I don't think that QHash is such a good idea. Currently compilers from that map dispayed to the user in an ordered manner: "gcc c99", "gcc c++03", "gcc c++11" e.t.c. With QHash they can be displayed in a random order, that's not very good IMO. Also I see no performance benefit, as there are less then ~10 elements.


> On Jan. 7, 2015, 5:55 p.m., Milian Wolff wrote:
> > languages/plugins/custom-definesandincludes/compilerprovider/compilerprovider.cpp, line 137
> > <https://git.reviewboard.kde.org/r/121777/diff/2/?file=338578#file338578line137>
> >
> >     this is unrelated to this patch no? and does this really still occur? there cannot be a ProjectBaseItem without either projectAboutToBeOpened or projectOpened signals, no?

>and does this really still occur?

Yes, it does. Seems like with that patch it happens even more often (I could be misled, though)

>there cannot be a ProjectBaseItem without either projectAboutToBeOpened or projectOpened signals, no?

I don't know, seems like CompilerProvider::projectOpened gets triggered right after the first call to the CompilerProvider::includes...


- Sergey


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121777/#review73367
-----------------------------------------------------------


On Jan. 8, 2015, 3:09 p.m., Sergey Kalinichev wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121777/
> -----------------------------------------------------------
> 
> (Updated Jan. 8, 2015, 3:09 p.m.)
> 
> 
> Review request for KDevelop.
> 
> 
> Repository: kdevelop
> 
> 
> Description
> -------
> 
> Now we can choose different language standards for computing standard include directories/defined macros. 
> Also this feature is very useful for the kdev-clang plugin (Now it's possible to parse plain C projects).
> 
> 
> Diffs
> -----
> 
>   languages/plugins/custom-definesandincludes/compilerprovider/compilerfactories.h 00042fb 
>   languages/plugins/custom-definesandincludes/compilerprovider/icompiler.cpp 0bf6a44 
>   languages/plugins/custom-definesandincludes/compilerprovider/icompilerfactory.h 3849bcb 
>   languages/plugins/custom-definesandincludes/compilerprovider/compilerfactories.cpp 8d47690 
>   languages/plugins/custom-definesandincludes/compilerprovider/compilerprovider.cpp 3643e78 
>   languages/plugins/custom-definesandincludes/compilerprovider/gcclikecompiler.h 079b78d 
>   languages/plugins/custom-definesandincludes/compilerprovider/gcclikecompiler.cpp bc99d8d 
>   languages/plugins/custom-definesandincludes/compilerprovider/icompiler.h 3627ebd 
>   languages/plugins/custom-definesandincludes/compilerprovider/msvccompiler.h a59a6b7 
>   languages/plugins/custom-definesandincludes/compilerprovider/msvccompiler.cpp fcd9db7 
>   languages/plugins/custom-definesandincludes/compilerprovider/settingsmanager.cpp 229f456 
>   languages/plugins/custom-definesandincludes/kcm_widget/compilerswidget.cpp aebbf5a 
>   languages/plugins/custom-definesandincludes/kcm_widget/compilerswidget.ui 0c90cee 
>   languages/plugins/custom-definesandincludes/kcm_widget/definesandincludesconfigpage.cpp 75f224d 
>   languages/plugins/custom-definesandincludes/kcm_widget/projectpathswidget.cpp 5b34e75 
>   languages/plugins/custom-definesandincludes/kcm_widget/projectpathswidget.ui 3e413b3 
> 
> Diff: https://git.reviewboard.kde.org/r/121777/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Sergey Kalinichev
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20150108/301a394c/attachment.html>


More information about the KDevelop-devel mailing list