Now down to 21 pages. Aiming for 10. :-)

Author: potanin

papers/ACSC2017/background.tex

@@ -7,40 +7,3 @@ \section{Conclusion}\label{C:con}
 At the moment the provided tool supports renaming of local and global variables, fields, function arguments, structs, enum and functions (or methods). Beyond renaming, it also allows reification and elision of lifetime parameters for functions and methods and has preliminary support for inlining of local variables. These refactorings in particular highlight the idiosyncrasies of Rust, ensuring that the analyses performed here are some of the first of its kind. The complete limitations of these refactorings are not yet fully known, but there exists a current suite of tests to ensure that there are no obvious flaws in the approach. The presence of bugs in the compiler is a real problem to generality, but without real world use and more contribution to testing, finding these corner cases appears to be difficult.
 
 At the moment, Rust lacks significant refactoring tool-support and evidently requires more work particularly within the compiler to enable further, valuable progress. Although a preliminary tool has been provided, there are many avenues for continuing work and the hope is that this first investigation provides useful insight for future efforts. Understanding the required context and the necessary infrastructure has been a major part of this work. In particular, learning and understanding Rust has been incredibly challenging, as it introduces concepts rarely used elsewhere. Continuation of this work should allow greater focus on implementing a more difficult and comprehensive set of refactorings for Rust.
-
-\section{Appendix}\label{C:appen}
-\section{Eclipse refactorings}
-\begin{center}
-\begin{figure}
-\scalebox{0.9}{
-\begin{tabular}{ l | l | l }
-Rename &
-Move &
-Extract Method \\
-Extract Local Variable &
-Extract Constant &
-Inline \\
-Move Type to New File &
-Extract Superclass &
-Extract Interface \\
-Push Down &
-Pull Up &
-Extract Class \\ 
-Introduce Indirection &
-Introduce Factory &
-Introduce Parameter \\
-Encapsulate Field &
-Generalize Declared Type &
-Migrate JAR File \\
-Change Method Signature &
-Convert Anon. Class to Nested &
-Convert Local Variable to Field \\
-Use Supertype Where Possible &
-Introduce Parameter Object &
-Infer Generic Type Arguments
-\end{tabular}
-}
-\caption{List of refactorings supported by Eclipse}
-\label{Fig:eclipse}
-\end{figure}
-\end{center}

papers/ACSC2017/conclusion.tex

@@ -18,7 +18,7 @@ \subsection{Validity of refactorings}\label{S:validity}
 \subsubsection{Validity of renamings}
 The testing suite attempts to test both the cases where a renaming should occur, and cases where it should not due to the variations in conflict types as outlined in Section \ref{S:different}. Currently there around 60 tests specifically written to test renaming, spread across the different classes of renaming. In particular, tests try to cause conflicts between the different classes, e.g. variable names with type names. We can examine a generic rename in Figure \ref{Fig:walk}. When running any of the renaming refactorings, name resolution will run to find any super-block conflict or some cases same-block conflicts. Afterwards, any sub-block conflicts will be caught in a compilation run. In some cases, the `use' import graph is then rebuilt to identify same-block conflicts which were missed by name resolution. By convincing ourselves that all the conflict types are covered, in addition the having test cases to show that it works, there can be confidence that the overall approach works.
 
-\begin{figure}
+\begin{figure*}
 {\verb|let a = 2; // 1. Super-block conflict: caught by name resolution|}
 
 {\verb|    {|}
@@ -32,7 +32,7 @@ \subsubsection{Validity of renamings}
 {\verb|    }|}
 \caption{Examining a tentative rename in red}
 \label{Fig:walk}
-\end{figure}
+\end{figure*}
 
 \paragraph{Local and global variables (and generally function arguments and fields)}
 At the moment there exists several tests for const, static and normal local variables, both in successful and non-successful situations. In terms of the ability for this class of renamings to fail unexpectedly, the chances appear slight since variables lack the most dynanism and complexity (no dynamic dispatch for instance), particularly for local variables. As long as name resolution works correctly and the compilation process, few of these renamings should cause issues. During the process of testing, it was found that `static mut' global variables did not record their spans correctly due to an error in the save-analysis code. In particular, the span was recorded for the `mut' identifier as opposed to the actual name of the variable. Fixing this required a minor patch to the Rust compiler and this patch was upstreamed prior to the release of Rust 1.0.
@@ -233,9 +233,9 @@ \subsubsection{Comparing the timings between the types of refactorings}
 
 \begin{figure}[h]
 \begin{center}
-\scalebox{0.8}{
-\includegraphics{refactorings}
-}
+
+\includegraphics[width=8cm]{refactorings}
+
 \caption{Graph displaying results of the different refactorings}
 \label{Fig:compareref}
 \end{center}
@@ -268,9 +268,9 @@ \subsubsection{Varying the number of refactoring locations or usages}
 
 \begin{figure}[h]
 \begin{center}
-\scalebox{0.8}{
-\includegraphics{scaling}
-}
+
+\includegraphics[width=8cm]{scaling}
+
 \caption{Graph displaying results of varying the number of usages}
 \label{Fig:comparerefs}
 \end{center}

papers/ACSC2017/evaluation.tex

@@ -56,7 +56,7 @@ @misc{docmod15
 @misc{openhub15,
     author = "{Black Duck Open HUB}",
     title = {{Rust (programming language)}},
-    howpublished = {\url{http://code.openhub.net/project?pid=&ipid=301463}},
+    howpublished = {\url{code.openhub.net/project?pid=&ipid=301463}},
     year=2015,
 }
 
@@ -177,7 +177,7 @@ @phdthesis{brown2008tool
 @article{baumer2001integrating,
   title={Integrating refactoring support into a Java development tool},
   author={B{\"a}umer, Dirk and Gamma, Erich and Kiezun, Adam},
-  journal={OOPSLA’01 Companion},
+  journal={OOPSLA'01 Companion},
   year={2001}
 }