Bug #6082
automatically add to conversion list all non-skeleton .cls dependencies
0%
Related issues
History
#1 Updated by Constantin Asofiei about 2 years ago
During conversion, if a .cls or a .p has dependencies to non-skeleton classes which are not included in the initial conversion list, the conversion will fail at some point in the annotations or main conversion phase.
The parsing phase can be improved to recursively include all .cls files (loaded during parsing phase and which are not part of the conversion list), until no more new .cls files are loaded.
#2 Updated by Greg Shah about 2 years ago
- Related to Feature #5630: add missing classes referenced during parsing to the conversion list in file list mode added
#3 Updated by Greg Shah about 2 years ago
This may be a duplicate of #5630.
#4 Updated by Constantin Asofiei about 2 years ago
In #6351-10 Greg Shah wrote:
Sub-classes should be re-converted every time a parent class is converted.
This is a real issue, as the converted Java method name in sub-classes must match the one in the parent class.
Of course, on each step this will require to go back and check for all references/sub-classes/etc until none are left.
#6 Updated by Constantin Asofiei about 1 year ago
Greg, the changes which helped me get through the 62k files for #7199 are in 6082a rev 14553 (created from trunk rev 14552). I don't really like the approach (and SymbolResolver.parseHierarchy may lose .cls dependencies), but I just wanted to archive these changes, so they do not get lost. It also breaks (again) concurrent conversion or parsing.
#7 Updated by Greg Shah about 1 year ago
- Related to Feature #7169: drive conversion order using user-specified dependencies added
#8 Updated by Greg Shah about 1 year ago
- Related to Feature #7180: create a centralized manager for the conversion list and per-file/project status and logging added
#9 Updated by Greg Shah about 1 year ago
I've looked at the changes. Yes, you are right that they are not something we could pull into trunk as is. I had similar code to this and had to remove it because it did not result in the correct list. I went in favor of the current wa.processed approach used during pre-scan which was also nasty but I did get it working reliably.