You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
title=\lstname% show the filename of files included with \lstinputlisting; also try caption instead of title
27
27
}
28
28
@@ -43,7 +43,7 @@
43
43
\begin{abstract}
44
44
The current documentation tool (Dottydoc) relies on compiler internals and low-level code. The tool introduced in this work aims to build a program that does not depend on compiler internals but instead uses TASTy files. The latter become output when a Scala program is compiled.
45
45
46
-
This work also aims at providing a bettermaintained tool with fewer bugs and more features.
46
+
This work also aims at providing a better-maintained tool with fewer bugs and more features.
47
47
48
48
The documentation files are in Markdown instead of the commonly used HTML.
49
49
\end{abstract}
@@ -64,7 +64,7 @@ \chapter{Introduction}
64
64
65
65
The tool was developed with a few goals in mind. First, it should be independent of the compiler, hence the use of TASTy files. It should also produce humanly consumable files, hence the choice of Markdown as an output. Finally, it should have as many features as Dottydoc and be as easily maintainable.
66
66
67
-
The report is organized in the following structure: First, we will talk about the features of the tool. Then, we will give a high-level and a low-level architectural description. Dottydoc and Tastydoc will then be compared. We will finally talk about the problems encountered during the development and the further work needed.
67
+
The report is organized in the following structure: First, we will talk about the features of the tool. Then, we will give a high-level and low-level architectural description. Dottydoc and Tastydoc will then be compared. We will finally talk about the problems encountered during the development and the further work needed.
68
68
69
69
\chapter{Features}
70
70
We will list here the most important features of Tastydoc. For a comparison with Dottydoc features see \autoref{sec:comparison}.
@@ -116,7 +116,7 @@ \subsection{High-level API}
116
116
The tool offers an interface that is easy to use (called Representation, see \autoref{sec:representation}) to access all the information about an entity in a comprehensible format for anyone willing to write their own documentation tool without worrying to consume TASTy files.
117
117
118
118
\subsection{Reuse of Dottydoc intermediate representation}
119
-
The intermediate structure (Representation) is similar to Dottydoc \texttt{Entity}\footnote{\texttt{dotty/tools/dottydoc/Entity.scala}} allowing to easily reuse parts of Dottydoc code with only minor modifications. Right now, the tool uses parts of Dottydoc code for parsing user documentation. However, it could produce the same HTML files as Dottydoc without relying on compiler internals. Especially since Dottydoc already has a complex templating mechanism that allows to attach blog posts to documentation and a search engine.
119
+
The intermediate structure (Representation) is similar to Dottydoc \texttt{Entity}\footnote{\texttt{dotty/tools/dottydoc/Entity.scala}} allowing to easily reuse parts of Dottydoc code with only minor modifications. Right now, the tool uses parts of Dottydoc code for parsing user documentation. However, it could produce the same HTML files as Dottydoc without relying on compiler internals. Especially since Dottydoc already has a complex templating mechanism that allows attaching blog posts to documentation and a search engine.
120
120
121
121
\section{Low-level architecture}
122
122
\subsection{TastyExtractor}
@@ -190,7 +190,7 @@ \subsection{Representation}
190
190
\subsection{DocPrinter}
191
191
File: \texttt{dotty/tastydoc/DocPrinter.scala}
192
192
193
-
Object with methods that formats Representations and References to Markdown and writes them to files. Basically, it handles all the formatting and writting logic of the tool.
193
+
Object with methods that formats Representations and References to Markdown and writes them to files. Basically, it handles all the formatting and writing logic of the tool.
194
194
195
195
\subsection{mdscala}
196
196
File: \texttt{dotty/tastydoc/mdscala.scala}
@@ -260,7 +260,7 @@ \section{Extra features from Tastydoc}
260
260
Tastydoc keeps track of all seen subclasses of a class and links to their documentation files.
261
261
262
262
\paragraph{Refined types}
263
-
Tastydoc handles refined types where Dottydoc only remember the parent of the type.
263
+
Tastydoc handles refined types where Dottydoc only remembers the parent of the type.
264
264
265
265
\section{Bugs in Dottydoc that Tastydoc fixes}
266
266
Dottydoc is not really maintained and hence does not follow the evolution in Master. Some bugs are present in Dottydoc. Tastydoc fixes them all.
@@ -299,7 +299,7 @@ \chapter{Problems}
299
299
A few problems were encountered during the tools' development, some could not be fixed for reasons detailed below.
300
300
301
301
\paragraph{Markdown escaping}
302
-
We need a library to create a Markdown AST and render it to text, because the output is written in Markdown. The library also needs to escape the input. For instance, a method named "\#", will be interpreted as a header of level 1 if it is not escaped which is not the expected behaviour. This creates a problem because no such library exists in Java or Scala and taking care of Markdown escaping would be time-consuming and was not the main topic of this project.
302
+
We need a library to create a Markdown AST and render it to text because the output is written in Markdown. The library also needs to escape the input. For instance, a method named "\#", will be interpreted as a header of level 1 if it is not escaped which is not the expected behaviour. This creates a problem because no such library exists in Java or Scala and taking care of Markdown escaping would be time-consuming and was not the main topic of this project.
303
303
304
304
\paragraph{Linking inside code blocks}
305
305
We use code blocks indicating we have a piece of code so that a signature is formatted and syntax highlighted. In these code blocks, we also want to be able to make links pointing to the documentation page of a type. Unfortunately, Markdown fenced code blocks do not allow to have links in them. To counter this problem, we use HTML pre and code tag which are also understood by Markdown viewer. However, that causes two problems. First, it is not pure Markdown. Second, we lose the language syntax highlight from Markdown fenced code blocks.
@@ -312,6 +312,9 @@ \chapter{Problems}
312
312
313
313
To mitigate this problem, we first output types and then values so that when linking it links to the first one appearing in the page which would be a type and it is what we want in most cases. However, this does not solve the problem of linking to type parameters and of linking to overloaded methods.
314
314
315
+
\paragraph{Bug when calling owner}
316
+
At the time of writing the documentation tool display methods inherited from Object and Any and not overridden (which is not the desired behaviour) because a bug in Dotty makes the program crash when calling \texttt{owner} of a symbol.
317
+
315
318
\chapter{Further work}
316
319
Although the project is nearly complete, some work needs to be done to perfect the tool.
317
320
@@ -340,8 +343,4 @@ \chapter{Further work}
340
343
\paragraph{HTML/CSS}
341
344
Markdown files for documentation are good for all the reasons mentioned in this report. However, some people still want a good HTML/CSS documentation. The aim would be to either take back what Dottydoc has and use it with our code or build something new. The first case would be pretty straightforward as our intermediate representation looks very similar to Dottydoc. The biggest modification would be made to the References as links are handled a bit differently in this tool.
342
345
343
-
\end{document}
344
-
345
-
%Say that dottydoc does not have these features in problems?
0 commit comments