This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
CND is implementing C/C++ static code analyzer (private module) by reusing the Static Analysis Core API. There is a problem when the inspector is invoked: - the class Analyzer.Context contains empty scope if the project scope is selected. List of source roots is empty because the list is filled by project's class paths. C/C++ project does not provide class paths (due to performance problem with parsing API). Please provide class path (java) independent way to select the project scope. Please reassign bug to right product/component if I selected wrong one.
(In reply to comment #0) > CND is implementing C/C++ static code analyzer (private module) by reusing the > Static Analysis Core API. Good! > There is a problem when the inspector is invoked: > - the class Analyzer.Context contains empty scope if the project scope is > selected. > List of source roots is empty because the list is filled by project's class > paths. > C/C++ project does not provide class paths (due to performance problem with > parsing API). > Please provide class path (java) independent way to select the project scope. Strictly speaking, the API is not CP oriented (there is no mention of CP in the API/SPI, to my knowledge). Not even the implementation is not CP oriented - it uses the CP as a fallback, as most projects are use CP to bind to the rest of the IDE (otherwise we would need to add support for static analysis to *all* existing projects, which feels insane to me). In fact, there is a way to specify the project's Scope: include the Scope in the project's lookup. This Scope takes precedence over everything else (and I do use it for a non-Java project). The downside is that maintaining the Scope is project's lookup is not particularly trivial. I am thinking about a ScopeProvider to support other features, and it might be usable even for code.analysis, eliminating the need to maintain the Scope itself in the Lookup. But I suggest to use the Scope for the time being, until the ScopeProvider is (or is not) sorted out. For the record, there was another approach that used the generic source group as the final fallback when nothing else was available, but I had to drop it, due to very serious performance problems. > > Please reassign bug to right product/component if I selected wrong one.
(In reply to comment #1) > (In reply to comment #0) > In fact, there is a way to specify the project's Scope: include the Scope in > the project's lookup. This Scope takes precedence over everything else (and I > do use it for a non-Java project). The downside is that maintaining the Scope > is project's lookup is not particularly trivial. Yes, it is not trivial. By the way C/C++ project has Sources in the lookup. Probably it is enough? (If project does not register class paths, ask project lookup for Sources). > I am thinking about a > ScopeProvider to support other features, and it might be usable even for > code.analysis, eliminating the need to maintain the Scope itself in the Lookup. It will resolve the problem. > But I suggest to use the Scope for the time being, until the ScopeProvider is > (or is not) sorted out. I'd prefer to wait ScopeProvider.
(In reply to comment #2) > (In reply to comment #1) > > (In reply to comment #0) > > In fact, there is a way to specify the project's Scope: include the Scope in > > the project's lookup. This Scope takes precedence over everything else (and I > > do use it for a non-Java project). The downside is that maintaining the Scope > > is project's lookup is not particularly trivial. > > Yes, it is not trivial. > By the way C/C++ project has Sources in the lookup. > Probably it is enough? (If project does not register class paths, ask project > lookup for Sources). Thats what I was referring to with the generic source group. The Sources can be used in two ways: to get the generic source group, which was done originally, but as a consequence the whole subfolder of module suite projects was scanned, leading to terrible performance when any module suite was among the selected projects. Or the C/C++ source group(s) keys would need to be hardcoded in code.analysis, but the API could hardly be considered to be language agnostic after that.
Could you please check if this is sufficient: http://hg.netbeans.org/jet-main/rev/c35e26c7a72a Thanks.
Integrated into 'main-golden', will be available in build *201209060001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/c35e26c7a72a User: Jan Lahoda <jlahoda@netbeans.org> Log: #216856: introducing AnalysisScopeProvider to get a Scope from a Project.
What about using DataFolder in a node lookup. C/C++ projects do not know "package" (NonRecursiveFolder in a node lookup for java). Instead C/C++ projects know "folder" (DataFolder in a node lookup).
(In reply to comment #6) > What about using DataFolder in a node lookup. I would rather no do that - other project type may have the DF in the Lookup for other purposes, and it may lead to unexpected results. Moreover, not sure if that would solve the C/C++ project situation: I always though individual files (regardless of their enclosing directories) can be added to the project? What DF would be sent to the Scope in such a case? How would be the DFs in the Lookup maintained? > C/C++ projects do not know "package" (NonRecursiveFolder in a node lookup for > java). Instead C/C++ projects know "folder" (DataFolder in a node lookup). So don't use the NRF bucket. I assumed C/C++ project would use the "files" bucket on Scope (isn't the C/C++ project a bunch of files?), but I think you can use the source roots if you wish (which is intended to be recursive).
Jan, can we remove dependency from Refactoring API? Otherwise make project now has this dependency and other applications based on cnd source base now are broken, because refactoring is excluded from platform.
(In reply to comment #7) > (In reply to comment #6) > > What about using DataFolder in a node lookup. > > I would rather no do that - other project type may have the DF in the Lookup > for other purposes, and it may lead to unexpected results. > > Moreover, not sure if that would solve the C/C++ project situation: I always > though individual files (regardless of their enclosing directories) can be > added to the project? What DF would be sent to the Scope in such a case? How > would be the DFs in the Lookup maintained? > > > C/C++ projects do not know "package" (NonRecursiveFolder in a node lookup for > > java). Instead C/C++ projects know "folder" (DataFolder in a node lookup). > > So don't use the NRF bucket. I assumed C/C++ project would use the "files" > bucket on Scope (isn't the C/C++ project a bunch of files?), but I think you > can use the source roots if you wish (which is intended to be recursive). C++ project has different views over source tree. One of this views (for projects from existing sources) reflects physical structure. It might be expected by user to reduce inspect analysis to "folder" subtree (so recursively). Any advice how to achieve it? Looks like RunAnalysisPanel should be ready for such requests as well or we should be able to create Scope over folder (recursively)
(In reply to comment #8) > Jan, can we remove dependency from Refactoring API? Otherwise make project now > has this dependency and other applications based on cnd source base now are > broken, because refactoring is excluded from platform. Not quite clear to me: are these applications going to use the static code analysis? If no, than the easiest way out I see is to create a bridge module between cnd.make.project and code.analysis instead of making cnd.make.project directly dependent on code.analysis. If yes, the situation would be more complex - not only we would have to duplicate Scope (or a similar facility), but also would be more difficult not to break existing clients. Also, would make it more difficult for code.analysis to use the standard Scope selector (not using it now, but I hope it will be possible eventually).
(In reply to comment #9) > (In reply to comment #7) > > (In reply to comment #6) > > > What about using DataFolder in a node lookup. > > > > I would rather no do that - other project type may have the DF in the Lookup > > for other purposes, and it may lead to unexpected results. > > > > Moreover, not sure if that would solve the C/C++ project situation: I always > > though individual files (regardless of their enclosing directories) can be > > added to the project? What DF would be sent to the Scope in such a case? How > > would be the DFs in the Lookup maintained? > > > > > C/C++ projects do not know "package" (NonRecursiveFolder in a node lookup for > > > java). Instead C/C++ projects know "folder" (DataFolder in a node lookup). > > > > So don't use the NRF bucket. I assumed C/C++ project would use the "files" > > bucket on Scope (isn't the C/C++ project a bunch of files?), but I think you > > can use the source roots if you wish (which is intended to be recursive). > C++ project has different views over source tree. One of this views (for > projects from existing sources) reflects physical structure. It might be > expected by user to reduce inspect analysis to "folder" subtree (so > recursively). > Any advice how to achieve it? Looks like RunAnalysisPanel should be ready for > such requests as well or we should be able to create Scope over folder > (recursively) Thats a situation for which (I think) using the standard Scope selector is most appropriate - that one is pluggable, allowing Java projects to plug in packages, and anybody else plug their own views.
(In reply to comment #10) > (In reply to comment #8) > > Jan, can we remove dependency from Refactoring API? Otherwise make project now > > has this dependency and other applications based on cnd source base now are > > broken, because refactoring is excluded from platform. > > Not quite clear to me: are these applications going to use the static code > analysis? If no, than the easiest way out I see is to create a bridge module > between cnd.make.project and code.analysis instead of making cnd.make.project > directly dependent on code.analysis. If yes, the situation would be more > complex - not only we would have to duplicate Scope (or a similar facility), > but also would be more difficult not to break existing clients. Also, would > make it more difficult for code.analysis to use the standard Scope selector > (not using it now, but I hope it will be possible eventually). I'm not that deep into the subject, but Jan's idea towards avoiding direct dependencies sounds attractive to me.
Integrated into 'main-golden', will be available in build *201209120001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/18fa272d3b56 User: Alexander Simon <alexvsimon@netbeans.org> Log: provide scope provider of C/C++ project according to Bug #216856 Static code analysis API is class path oriented
(In reply to comment #10) > (In reply to comment #8) > > Jan, can we remove dependency from Refactoring API? Otherwise make project now > > has this dependency and other applications based on cnd source base now are > > broken, because refactoring is excluded from platform. > > Not quite clear to me: are these applications going to use the static code > analysis? If no, than the easiest way out I see is to create a bridge module > between cnd.make.project and code.analysis instead of making cnd.make.project > directly dependent on code.analysis. If yes, the situation would be more > complex - not only we would have to duplicate Scope (or a similar facility), > but also would be more difficult not to break existing clients. Also, would > make it more difficult for code.analysis to use the standard Scope selector > (not using it now, but I hope it will be possible eventually). Alexander, please, move scope provider from makeproject into oss and register it under Projects/org-netbeans-modules-cnd-makeproject/Lookup in layer.xml (probably there is a corresponding annotation for that)
@ProjectServiceProvider(projectType="org-netbeans-modules-cnd-makeproject", service=AnalysisScopeProvider.class)
Alexandr, Vladimir, are you OK with the current state of the API, or do you need some changes? Thanks.
(In reply to comment #16) > Alexandr, Vladimir, are you OK with the current state of the API, or do you > need some changes? Thanks. The project and file scope works perfect. But I do not understand how to provide folder scope.
Also selection of several files does not work as "scope".
Please provide way to select several source files and folders. It is a stopper for C/C++ static analyzer. Please fix it in NB 8.0.
Created attachment 144708 [details] add folder scope
Thank you for the patch. I check it with java projects, if there is nothing broken. http://hg.netbeans.org/jet-main/rev/c2cf661ee781
Integrated into 'main-silver', will be available in build *201402050001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-silver/rev/c2cf661ee781 User: Milutin Kristofic <mkristofic@netbeans.org> Log: #216856 - Static code analysis API is class path oriented (can not inspect content of Folder)