Bugzilla – Full Text Bug Listing
| Summary: | [Refactoring] Convert Spec Stmt to Decl Attrib - CQ Approved [Contrib] | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Tools] PTP | Reporter: | Jing Vergara <vergara5> | ||||||||
| Component: | Photran.Refactoring Engine | Assignee: | Jeffrey Overbey <com-eclipse-dot-org> | ||||||||
| Status: | CLOSED WONTFIX | QA Contact: | |||||||||
| Severity: | enhancement | ||||||||||
| Priority: | P2 | CC: | anu_pardeshi, com-eclipse-dot-org, fredlhsu, M19U3LD142, vergara5 | ||||||||
| Version: | unspecified | ||||||||||
| Target Milestone: | --- | ||||||||||
| Hardware: | All | ||||||||||
| OS: | All | ||||||||||
| Whiteboard: | |||||||||||
| Attachments: |
|
||||||||||
Created attachment 184833 [details]
Project Documentation
Hi all, Thanks a lot for the contribution! It looks good overall... there are just a few minor issues I'd like you to fix before we send this on for an IP review. Please re-submit the patch with these changes: 1. The copyright header is incorrect for ConvertSpecificationStatementsAction -- it assigns copyright to UIUC. 2. "M" is missing from "Miguel" in the copyright header for ASTSpecificationStmtNode. 3. Please fix the Java code formatting to match the other refactoring classes (notably, put opening braces on the next line). The easiest way to do this is probably to select the relevant code and click on Source > Format, although if you do that, please skim the code afterwards to make sure the formatter didn't do anything too unseemly. Thanks a lot! Jeff Created attachment 185106 [details]
Updated patch to fix issues
Thanks a lot! Miguel, Jing, Fred, and Anu, could *each* of you please confirm (as a comment on this bug) that 1. you wrote 100% of the code without incorporating content from elsewhere or relying on the intellectual property of others, 2. you have the right to contribute the code to Eclipse, and 3. you have included the EPL license header in all source files? Jing Vergara: 1. I wrote 100% of the code without incorporating content from elsewhere or relying on the intellectual property of others, 2. I have the right to contribute the code to Eclipse, and 3. I have included the EPL license header in all source files 1. I wrote 100% of the code without incorporating content from elsewhere or relying on the intellectual property of others, 2. I have the right to contribute the code to Eclipse, and 3. I have included the EPL license header in all source files Fred Hsu: 1. I wrote 100% of the code without incorporating content from elsewhere or relying on the intellectual property of others, 2. I have the right to contribute the code to Eclipse, and 3. I have included the EPL license header in all source files As soon as I get a confirmation from Miguel, we can start the IP review process... 1. I wrote 100% of the code without incorporating content from elsewhere or relying on the intellectual property of others, 2. I have the right to contribute the code to Eclipse, and 3. I have included the EPL license header in all source files Miguel Diaz Thanks! For the IP review, I will need to describe how much of the work was done by each person involved. Generally, for CS427 projects, the work was more-or-less evenly distributed, so I will use the following breakdown unless you inform me otherwise: Miguel Diaz - 25% Jing Vergara - 25% Fred Hsu - 25% Anu Pardeshi - 25% I'll start the IP review process soon. If the IP team has any questions, I'll post them here. CQ 4699 Submitted - https://dev.eclipse.org/ipzilla/show_bug.cgi?id=4699 The CQ was approved. Check in to CVS pending. Unfortunately, there is no longer active development on this component. |
Created attachment 184832 [details] Source code and tests Convert specification statement to declaration attribute refactoring replaces the various specification statements (DIMENSION, PARAMETER, SAVE, etc.), with the attribute declarations in the variables' type declaration statements. In a high-level view, this would involve: 1. looking for the proper specification statement selected by the user 2. validating the specification statement a. checking for IMPLICIT NONE b. checking for valid ordering of variables and parameter declarations c. checking that the variables in the selected specification statement have corresponding type declarations 3. performing the conversion of the specification statement a. set the specification attribute in the variables’ type declaration i. in the case of a DIMENSION statement, setting the dimension information into the DIMENSION attribute or next to the variable name b. moving the comments c. moving the statement labels (ensure that this is only done once as it will cause compiler errors if the statement labels get duplicated) 4. performing special handling a. in the case of a PRIVATE statement, adding the PRIVATE statement for subprograms b. splitting the variables in the type declaration to separate the variables that will have specification attributes and the ones that are not c. splitting the DIMENSION variables 5. delete the specification statement