spoon
spoon copied to clipboard
Suggestion: split setIgnoreSyntaxErrors flag into 2 flags, setIgnoreSyntaxErrors and setIgnoreSemanticErrors
Hi,
does spoon work on un-compilable source code as input? i.e syntax correct but semantics wrong source code?
un-compilable: means not accepted by the regular javac
compiler; but the syntax is correct.
E.g. I have some old Java code, that is syntax correct, but semantics wrong (e.g. missing some class type decls); I plan to use spoon first transform and generate some new code, and only compile the final new code.
Does spoon work in this scenario? or the old code has to be compilable first to use spoon?
Can spoon do partial semantic analysis? i.e do it as much as it can, but do not abort on (undecidable) semantic errors?
Thanks.
Another question is: can I programmatically run the semantic analysis on list of classes?
Ideally, the classes need to be processed in topological dependency order in multiple passes:
1st pass: only establish the topological dependency order: e.g. [class A, class B, class C, class D ...] where only class A is compilable, the subsequent classes has dependency (either is-a or has-a relationship) on the preceding classes, so cannot be fully semantically analyzed until the preceding classes has been. And these classes [B, C, D ...] may contain other semantically un-compilable elements, so in the 1st pass only topological dependency order can be established. Let's call this partial semantic analysis.
2nd pass: class B is processed (with its complete dependency info on class A), now become compilable. The rest of [class C, class D ...] are partially semantic analyzed again.
3rd pass: class C is processed (with its complete dependency info on class A & B), now become compilable. The rest of [class D ...] are partially semantic analyzed again.
4th pass: ... and so on, until all done.
Is this multiple partial semantic analysis passes possible in spoon?
As the last resort, maybe I need to work at the AST level (i.e. only syntax, without semantic analysis), just wonder is there any AST level api doc / example / tutorial somewhere?
Thanks.
does spoon work on un-compilable source code as input? i.e syntax correct but semantics wrong source code?
Yes, we have a flag for it. See setIgnoreSyntaxErrors(boolean). This, I believe, should simplify the algorithm you mentioned in your second post. You can easily fix the errors directly on the model.
As the last resort, maybe I need to work at the AST level (i.e. only syntax, without semantic analysis), just wonder is there any AST level api doc / example / tutorial somewhere?
Spoon has a lot of its documentation on the website here
Does this answer your questions?
does spoon work on un-compilable source code as input? i.e syntax correct but semantics wrong source code?
Yes, we have a flag for it. See setIgnoreSyntaxErrors(boolean). This, I believe, should simplify the algorithm you mentioned in your second post. You can easily fix the errors directly on the model.
Ah, I want the opposite: setIgnoreSemanticErrors, can we add this flag?
(The syntax is correct)
does spoon work on un-compilable source code as input? i.e syntax correct but semantics wrong source code?
Yes, we have a flag for it. See setIgnoreSyntaxErrors(boolean). This, I believe, should simplify the algorithm you mentioned in your second post. You can easily fix the errors directly on the model.
Ah, I want the opposite: setIgnore_Semantic_Errors, can we add this flag?
(The syntax is correct)
Sorry, just realized: """ Sets the option ignore-syntax-errors to remove files with any syntax errors or JLS violations from the compilation batch. Also while transformations no checks for JLS correctness are reported as error. """
I think this flag should be split into two flags:
-- setIgnoreSyntaxErrors -- setIgnore_Semantic_Errors or (setIgnore_JLS_Errors, Java Language and Virtual Machine Specifications, but a bit hard to read).
I think this flag should be split into two flags:
We discussed this and came to the conclusion that we have enough flags and see no benefit in separating this. JLS errors and code that does not compile at all were too close for us to separate them.
I think this flag should be split into two flags:
We discussed this and came to the conclusion that we have enough flags and see no benefit in separating this. JLS errors and code that does not compile at all were too close for us to separate them.
However syntax, and semantic errors are processed at different compilation stages, and I have described my usage pattern: old code are syntax correct, but I need to use Spoon to post-process them (e.g.inject some new code snippets) to fix the semantic error.
Can we re-consider the decision to split into two flags.
There is one more problem with the current flag: currently it's mis-named. That's why I feel confused when I first saw the flag name. Right now it checks for both syntax and semantic error, then it should be called setIgnoreSyntaxAndSemanticErrors
or setIgnoreCompilationErrors
to avoid this confusion.
I was under the impression, that spoon ignores many (more or less benign) semantic errors by default. Do you have an example where your semantic errors cause a spoon exception where you would like them not to?
It seems to me like what you, @mw66, are looking for is to just run Spoon in noclasspath mode. Spoon will bend over backwards to try to make sense of code that does not compile for one reason or another (missing types, for example, which seemingly is your use case).
This is the default mode that Spoon runs in if you just create a Launcher
and go from there.