-
-
Notifications
You must be signed in to change notification settings - Fork 657
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[ide] collect_implementations
in statistics.ml
needs optimization
#9504
Comments
This one is pretty high-priority for us, because "find references" basically hangs in processing and I think it affects a lot of code. |
so far we've found out that |
this can happen a lot with interfaces involved, also this workarounds messy cl_dependants situation (see #9504 (comment))
ok, I couldn't spot actual cycles, so my new version is that it's just hundreds of duplicates of the very basic framework classes (e.g. Sprite), which has hundreds of duplicates of application base classes, which has hundreds of duplicates of concrete classes and so on, which leaves us with a huge amount of data to process so maybe it would finish if I gave it a day or so ^^ #9506 sidesteps this issue, but we still need to figure out why there are duplicates in |
More observations: Adding
Which is something I've actually seen before when checking some other issues, so I guess we also have a pokemon catch somewhere that swallows the assertion failure? ( |
I think I know where duplicates are coming from. We're calling haxe/src/context/display/findReferences.ml Line 101 in 9a75d9d
|
However, if I move "set up descendants" out and call it before the find_references loop, it still gets duplicates, and I don't know why. |
* minor collect_implementations cleanup did while trying to figure out #9504 * don't process already processed classes in collect_implementations this can happen a lot with interfaces involved, also this workarounds messy cl_dependants situation (see #9504 (comment))
* minor collect_implementations cleanup did while trying to figure out #9504 * don't process already processed classes in collect_implementations this can happen a lot with interfaces involved, also this workarounds messy cl_dependants situation (see #9504 (comment))
for any amount of symbols in an inheritance tree (closes #9504)
The text was updated successfully, but these errors were encountered: