Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] headless Eclipse

A little more information. I found out that in the headless mode, the include paths that are defined for the project are not used when it is resolving bindings.  

 

The problem is related to languageId being null when MBSLanguageSettingsProvider tried to match languageIds for one of the language settings.

 

Then, I tried to find why it is null and that led to this code in InputType.java#loadFromProject :

                                superClassId = SafeStringInterner.safeIntern(element.getAttribute(IProjectType.SUPERCLASS));

                                if (superClassId != null && superClassId.length() > 0) {

                                                superClass = ManagedBuildManager.getExtensionInputType(superClassId);

                                                if (superClass == null) {

                                                                // TODO:  Report error

                                                }

                                }

 

where superClass evaluates to null (and there’s some TODO there J), because it fails to find the extension for superClassId = cdt.managedbuild.tool.gnu.c.compiler.input. superClass is then used to evaluate languageId. I checked and this extension was not loaded. Only one in fact was loaded for the headless mode, which is: org.eclipse.cdt.build.core.settings.holder.inType)

So something goes wrong and not the same set of extensions is being loaded in the headless mode vs. regular Eclipse mode. Maybe we are launching the checkers in a wrong way. Here’s how the headless mode is operating:

 

    public Object start(IApplicationContext context) throws Exception {

        Object exitStatus = parseApplicationArguments(context);

        if (exitStatus != null) {

            return exitStatus;

        }

 

        CodanRuntime codanRuntime = CodanRuntime.getInstance();

        codanRuntime.setProblemReporter(new ConsoleProblemReporter());

 

        listCheckers();

 

        IWorkspaceRoot root = ResourcesPlugin.getWorkspace().getRoot();

        if (options.isRunOnWorkspaceRoot()) {

            Collection<IResource> rootSingleton = Collections.singletonList((IResource) root);

            runCheckersOnResources(rootSingleton);

        } else {

            List<IResource> resources = new ArrayList<>();

            for (String resourcePath : options.getResourcePaths()) {

                List<IResource> resourcesForPath = getResourcesForPath(root, resourcePath);

                if (resourcesForPath.isEmpty()) {

                    Messages.warning("Unresolved path: '" + resourcePath + "'");

                } else {

                    resources.addAll(resourcesForPath);

                }

            }

            runCheckersOnResources(resources);

        }

 

        return EXIT_OK;

    }

 

Please see if you can spot something wrong.

 

Thanks,

Andrey

 

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Ayupov, Andrey
Sent: Tuesday, January 27, 2015 10:06 AM
To: cdt-dev@xxxxxxxxxxx
Subject: [cdt-dev] headless Eclipse

 

Hi all,

 

We are trying to use Codan interface to run Eclipse in the headless (no GUI) mode to run checkers and having some problems.

The symptom we see is as follows. We have some external libraries for which we include some files. We can see that the indexer sees symbols from the includes, but IASTName.resolveBinding fails to resolve bindings that include symbols from those includes. Here is an example. We have a class (A) that derives from another class (sc_module) that is part of the external library (systemc.h). There’s a constructor in A that takes an argument of type “sc_module_name” defined in the base class “sc_module”. When we try to resolve the constructor binding using index, e.g. ctorBind = index.findBinding(indexNameOfCtor), it will find the right binding: A(sc_core::sc_module_name). After that if I try to find this binding using AST, then it fails. I do something like this: ast.getDefinitionsInAST(ctorBind), it returns null. The “ast” was created from index using the flag AST_SKIP_INDEXED_HEADERS. When debugging the getDefinitionsInAST function, I can see how the binding it found was A(?) (as opposed to the correct one - A(sc_core::sc_module_name)) and more digging showed that it couldn’t resolve either sc_module_name or sc_module.

So I assumed that AST should use index for such cases, but something is not working although the index knows about the symbols in the external library. Any suggestions where to look for hints?

 

Thanks,

Andrey


Back to the top