Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Improved semantics #322
This is the PR for the issue #321. It is not finished yet and has some regressions in tests that I have not fixed yet. Also misses tests for new functionality, but since it will take for me some more days to complete , and it has zillions of changes I create the PR already so you can start reviewing this.
- getMember and getMembers now works with extends and implements - Small refactorings - Fix importing classes - Implement throw, break and continue in expression evaluator - Implement EReg literals in expression evaluator - Added HaxeSuffixExpression to expression evaluator - Fixed Void -> XXX typetag function type - Supported anonymous typedefs
- Create method inside a body now detect arguments and return type - break and continue checks wether they are inside a loop - Added naming tools - Small fixes and improvements
…eturns Moved all else if code in expression evaluator to methods to reduce cyclomatic complexity and make it easier to read
Sorry for the delay. I have been in a business trip, and I didn't have too much time. I will read all the comments today.
Regarding to the next release: This improves the return type detection in some methods, at least when outlining due to improved resolving.
We can always disable the body semantic analyzer. Or even, just enable the missing semicolon part that could provide more value to developers without false positives.
Also completing the merge would reduce conflicts that if delayed.
But anyway you can skip this one if would interfere with your release.
Regards, and thanks for the hard reviewing!
@soywiz Hi Carlos, I haven't forgotten about this review. I've got a lot to do at the moment. And, you know 5K lines takes quite a while to review well. 8P I'll get back to it soon, but it may be next week.
Thanks for contributing -- and don't be discouraged!
…emantics Conflicts: src/common/com/intellij/plugins/haxe/ide/annotator/HaxeSemanticAnnotator.java src/common/com/intellij/plugins/haxe/model/HaxeClassModel.java src/common/com/intellij/plugins/haxe/model/HaxeParameterModel.java src/common/com/intellij/plugins/haxe/model/type/HaxeExpressionEvaluator.java
@soywiz Hi Carlos! As I remember, I had read about a third of the way through these changes. I had some comments that I thought should be addressed. I never got to finish the review, though, so there may be more things to think about.
In general, I think what I cared about most was that the models were caching information that could change underneath them. (Though, I admit, that is unlikely if they are very short-lived, as they are with the annotators.) That is, I REALLY prefer that the models do not hold any state, but that they make the underlying call to the PSI to get the current state when the data is requested. My main reasoning is that I like the models that you are developing; I find them much easier to conceptualize what is going on in the code. Therefore, I want to use them for other parts of the plugin which want to keep long(er)-lived objects: Things like the hierarchy panels, project structure, and the like.
I'll have to re-read this, though. Perhaps, in the interest of time, I'll not read so deeply.
I have merged master already and I have setup the development environment again.
It has passed a lot of time since last time and I don't remember too much about this, and I won't have too much time because now I have other priorities. After this gets merged I will be able to contribute in the future with smaller commits.
…ifiers) Created HaxeModifier interface, and split old modifiers into extra + visibility, so we can treat visibility in its own semantic enum (HaxeVisibility) Created HaxeModifiers abstract, so we can have two implementations: one with psi elements, and other with a plain list, but have common methods (that could be extension methods in kotlin or default methods in java8) #322 (comment)
Ok. So I have already fixed tests (I have disabled a couple of them that are not too important and will require more work on the semantic analyzer).
I really think that we should merge this already. I have put a lot of work on this. And I don't know wether I will be able to invest more time on this soon. Also fixing stuff commented here will require more time for me, and for you reviewing it.
The merge was awful, and took a lot of time, and there were things that were done again because this was not merged; so duplicated work.
From a pragmatic point of view I think we should merge this. Even if it is not perfect, you can continue the work from there and I get finally freed from this. I don't think I would handle a delay of another 6 months :) I won't remember anything as it happened this time and will need some time to get used to the code again.
After the merge you can get all the code you don't like, like the caching stuff, and removing or disabling it. Improve it iteratively and fixing stuff, even if there are regressions that are not covered in unittests.
I won't continue with this PR so I can go on with other stuff and free my mind (I was always thinking about this, and waiting to have time to merge and complete this; after all, this supposed a lot of work).
So if it won't get merged like it is already, please @as3boyan or @eliasku, fork Akamon/intellij-haxe/ImprovedSemantics, close this PR and create a new one. I will delete that fork and the branch next week for the sake of my mind sanity :)
Ok. Sorry. I won't remove it just yet, but I do not want to continue updating this PR. I highly prefer to contribute to fixes in small PRs after this gets merged. I know of several things that are not working or that could be improved and I was able to fix or improve them, but didn't want to make this bigger or to create another PR without being able to use the stuff I added here.