| Summary: | Non-local files cause InvalidArgumentException | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Tools] CDT | Reporter: | Greg Watson <g.watson> | ||||
| Component: | cdt-core | Assignee: | Markus Schorn <mschorn.eclipse> | ||||
| Status: | RESOLVED FIXED | QA Contact: | Doug Schaefer <cdtdoug> | ||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | beth | ||||
| Version: | 8.0 | Keywords: | contributed | ||||
| Target Milestone: | 8.0.1 | ||||||
| Hardware: | Macintosh | ||||||
| OS: | Mac OS X | ||||||
| Whiteboard: | |||||||
| Bug Depends on: | |||||||
| Bug Blocks: | 349204 | ||||||
| Attachments: |
|
||||||
|
Description
Greg Watson
Created attachment 198213 [details]
Fix for InvalidArgumentException
In earlier versions we intentionally did not create file-content objects for non-local file systems. The effect of this decision was, that we did not index remote file-systems, which is probably desirable. You seem to have a use-case where you do want to create a file-content object for a remote file. Can you describe the scenario (and provide a stack trace of the exception)? Greg, can you provide the stack-trace? Here's the stack trace. The exception occurs because FileCharArray tests if the input stream is a FileInputStream and returns null if not. This null is then passed to the InternalFileContent constructor at line 224 of InternalParserUtil#createFileContent(). The patch just creates a FileInputStream from the IFileStore if this is the case. java.lang.IllegalArgumentException at org.eclipse.cdt.internal.core.parser.scanner.InternalFileContent.<init>(InternalFileContent.java:75) at org.eclipse.cdt.internal.core.parser.InternalParserUtil.createFileContent(InternalParserUtil.java:224) at org.eclipse.cdt.internal.core.parser.InternalParserUtil.createWorkspaceFileContent(InternalParserUtil.java:158) at org.eclipse.cdt.core.parser.FileContent.create(FileContent.java:83) at org.eclipse.cdt.core.parser.FileContent.create(FileContent.java:67) at org.eclipse.cdt.internal.core.model.TranslationUnit.getAST(TranslationUnit.java:779) at org.eclipse.cdt.internal.core.model.TranslationUnit.getAST(TranslationUnit.java:768) at org.eclipse.ptp.pldt.common.actions.RunAnalyseHandlerBase.getAST(RunAnalyseHandlerBase.java:519) at org.eclipse.ptp.pldt.mpi.core.actions.RunAnalyseMPIcommandHandler.doArtifactAnalysis(RunAnalyseMPIcommandHandler.java:66) at org.eclipse.ptp.pldt.common.actions.RunAnalyseHandlerBase.analyse(RunAnalyseHandlerBase.java:149) at org.eclipse.ptp.pldt.common.actions.RunAnalyseHandlerBase.runResource(RunAnalyseHandlerBase.java:408) at org.eclipse.ptp.pldt.common.actions.RunAnalyseHandlerBase.runResources(RunAnalyseHandlerBase.java:625) at org.eclipse.ptp.pldt.common.actions.RunAnalyseHandlerBase$1.execute(RunAnalyseHandlerBase.java:310) at org.eclipse.ui.actions.WorkspaceModifyOperation$1.run(WorkspaceModifyOperation.java:106) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2344) at org.eclipse.ui.actions.WorkspaceModifyOperation.run(WorkspaceModifyOperation.java:118) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121) My motivation is to re-institue function that worked before the original UNC path change, and this worked for remote projects in the past and then stop working when https://bugs.eclipse.org/bugs/show_bug.cgi?id=343437 (Add support for UNC include directories) was implemented. Yes it's not very scalable (pull entire file down to get AST) but until I decide on and implement a more scalable solution I would like this to work as it used to on a remote file. Thanks, I have committed your patch. *** cdt git genie on behalf of Greg Watson ***
Bug 349730: Content for non-local files
[*] http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=ffca7f9d6bc38f101c22a80acafea04f18c5119b
*** cdt git genie on behalf of Greg Watson ***
Bug 349730: Content for non-local files
[*] http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=978d2d27895d7c42478f14b47b71a6f97fe4e84f
|