{"action":"created","issue":{"url":"https://api.github.com/repos/wenns/sonar-cxx/issues/272","labels_url":"https://api.github.com/repos/wenns/sonar-cxx/issues/272/labels{/name}","comments_url":"https://api.github.com/repos/wenns/sonar-cxx/issues/272/comments","events_url":"https://api.github.com/repos/wenns/sonar-cxx/issues/272/events","html_url":"https://github.com/wenns/sonar-cxx/issues/272","id":41281297,"number":272,"title":"The art of parsing","user":{"login":"guwirth","id":6077367,"avatar_url":"https://avatars.githubusercontent.com/u/6077367?v=3","gravatar_id":"","url":"https://api.github.com/users/guwirth","html_url":"https://github.com/guwirth","followers_url":"https://api.github.com/users/guwirth/followers","following_url":"https://api.github.com/users/guwirth/following{/other_user}","gists_url":"https://api.github.com/users/guwirth/gists{/gist_id}","starred_url":"https://api.github.com/users/guwirth/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/guwirth/subscriptions","organizations_url":"https://api.github.com/users/guwirth/orgs","repos_url":"https://api.github.com/users/guwirth/repos","events_url":"https://api.github.com/users/guwirth/events{/privacy}","received_events_url":"https://api.github.com/users/guwirth/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/wenns/sonar-cxx/labels/discussion","name":"discussion","color":"eb6420"}],"state":"open","locked":false,"assignee":null,"milestone":{"url":"https://api.github.com/repos/wenns/sonar-cxx/milestones/4","labels_url":"https://api.github.com/repos/wenns/sonar-cxx/milestones/4/labels","id":920882,"number":4,"title":"M 0.9.3","description":"Reaching this milestone should lead to the 0.9.3 release.","creator":{"login":"guwirth","id":6077367,"avatar_url":"https://avatars.githubusercontent.com/u/6077367?v=3","gravatar_id":"","url":"https://api.github.com/users/guwirth","html_url":"https://github.com/guwirth","followers_url":"https://api.github.com/users/guwirth/followers","following_url":"https://api.github.com/users/guwirth/following{/other_user}","gists_url":"https://api.github.com/users/guwirth/gists{/gist_id}","starred_url":"https://api.github.com/users/guwirth/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/guwirth/subscriptions","organizations_url":"https://api.github.com/users/guwirth/orgs","repos_url":"https://api.github.com/users/guwirth/repos","events_url":"https://api.github.com/users/guwirth/events{/privacy}","received_events_url":"https://api.github.com/users/guwirth/received_events","type":"User","site_admin":false},"open_issues":27,"closed_issues":17,"state":"open","created_at":"2015-01-04T08:15:36Z","updated_at":"2015-02-09T20:14:42Z","due_on":"2015-05-30T22:00:00Z","closed_at":null},"comments":19,"created_at":"2014-08-27T13:08:23Z","updated_at":"2015-02-13T09:12:09Z","closed_at":null,"body":"In the past we had already the discussion about the right way of 'error recovery' in the C++ plugin. In one of the discussion on the SonarQube community mailing list Dinesh Bolkensteyn stated:\r\n\r\n*Our previous approach with the C++ plugin was also to implement some recoveries, but we failed, and then changed our strategy. For more details on our new approach, you'll want to watch \"The Art Of Parsing\"* (http://sonarqube.15.x6.nabble.com/sonar-dev-SSLR-and-Error-Recovery-tt5020231.html#a5024335)\r\n\r\nNow I found a link to the presentation, but still don't know what this means for the community plugin?\r\n\r\n**The Art Of Parsing**\r\nhttp://de.slideshare.net/dbolkensteyn/the-art-of-parsing-devoxx-france-2014\r\nConclusion in this slides:\r\n* PEG: dead-end for C/C++\r\n* GLL: the only clean choice for C/C++"},"comment":{"url":"https://api.github.com/repos/wenns/sonar-cxx/issues/comments/74224819","html_url":"https://github.com/wenns/sonar-cxx/issues/272#issuecomment-74224819","issue_url":"https://api.github.com/repos/wenns/sonar-cxx/issues/272","id":74224819,"user":{"login":"jmecosta","id":1041352,"avatar_url":"https://avatars.githubusercontent.com/u/1041352?v=3","gravatar_id":"","url":"https://api.github.com/users/jmecosta","html_url":"https://github.com/jmecosta","followers_url":"https://api.github.com/users/jmecosta/followers","following_url":"https://api.github.com/users/jmecosta/following{/other_user}","gists_url":"https://api.github.com/users/jmecosta/gists{/gist_id}","starred_url":"https://api.github.com/users/jmecosta/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jmecosta/subscriptions","organizations_url":"https://api.github.com/users/jmecosta/orgs","repos_url":"https://api.github.com/users/jmecosta/repos","events_url":"https://api.github.com/users/jmecosta/events{/privacy}","received_events_url":"https://api.github.com/users/jmecosta/received_events","type":"User","site_admin":false},"created_at":"2015-02-13T09:12:09Z","updated_at":"2015-02-13T09:12:09Z","body":"In which state the java bindings are? A quick look in google did not point\nme to anything specific. By the way the dot ney plugin is implementing the\nmetrics also in native c# and roslyin. Maybe we can take some ideas from\nthere\n\nOn Fri, Feb 13, 2015, 10:34 Waleri Enns <notifications@github.com> wrote:\n\n> Personally, I think it is placing the interface too low to put a java\n> interface on the AST. IMO, the\n> entirety of the rule checks should be on the C++ side.\n>\n> You guys didnt understand me correctly. Or I wasnt clear enough. Im *not*\n> pleading for putting the focus on developing the checks in Java inside the\n> plugin. The built-in-checks we currently have are nice-to-have *at most*\n> and not strategically important. We dont put much effort in developing\n> those; most of them exist just because the port from some other plugin was\n> easy enough. Other people can do that (i.e. implement static code checking)\n> much better anyways.\n>\n> My point was that we have to turn the clang-AST in squid-compatible AST *for\n> other reasons*, namely to be able to stack all the other code (including\n> most of our metrics calculations) on top of it. And AFAICS, this is best\n> (i.e. with least effort) done using Java bindings to libclang. If they're\n> in decent shape and it works out.\n>\n> IMO, what you want to do is hand off the analysis to something like\n> clang-tidy or the clang static\n> analyzer and simply ingest the report from these tools. Heck, you're\n> already duplicating effort with\n> clang's static analyzer, clang-tidy and oclint, why suffer from NIH\n> syndrome when instead you can\n> just run these tools and ingest the results.\n>\n> Run tools and inject the results *we do*. Look at cppcheck, pclint, rats,\n> ... As already said, the built-in checks are just another rule engine,\n> which happens to be there. Ideally, static code checking support is tool\n> agnostic anyways, but for historical and some technical reasons (first of\n> all the rule repos, which are tied to particular tools) we have a number of\n> sensors handling this use case. But this may change in future, when SQ core\n> guys invent new ways of maintaining the rule metadata.\n>\n> —\n> Reply to this email directly or view it on GitHub\n> <https://github.com/wenns/sonar-cxx/issues/272#issuecomment-74220854>.\n>\n"}}