2 Fixing Bugs

2.2 Problems at compile time

In this section we look at how the compiler handles problems that it comes across in a project's source code. When we rebuilt Reversi in Section 2.1, the compiler discovered nine problems in the project's source code. It reported those problems and divided them into two categories: serious warnings and warnings.

The compiler issues a serious warning for code that would lead to an exception at run time if it was executed. Among the causes of serious warnings are Dylan syntax errors, references to undefined bindings, and calls to functions with the wrong number or type of arguments.

For code with only cosmetic problems, such as a method definition that ends with end class instead of end method, the compiler issues a warning.

You can see a table of any warnings or serious warnings that were generated the last time a project was compiled by choosing the Warnings page in the project window. After a build where there were warnings or serious warnings, like this one, the Warnings page is selected automatically.

Figure 2.1 The project window's Warnings page.

The table has four columns:

Source: Shows the source code location of the problem that caused the warning or serious warning. The column has the form {file name}:{line number}.
Library: Shows the library containing the source code that caused the warning.
Owner: Shows the problem area that caused the warning.
Warning: Shows the warning or serious warning message.

The items in the table are sorted lexically by the Source column value. Warnings and serious warnings without associated source locations have empty Source fields, and appear at the top of the list. (To sort the table by the values in another column, click on that column's header.)

Each warning or serious warning is linked to the source definition that caused it. We can select individual warnings and serious warnings to learn more about the problems they are describing.

: 1. Select the first item in the Source column, a serious warning in saving.dylan at line 20.

We can now see the full text of the serious warning:

Serious warning at saving:20: Unexpected token "define".

If we double-click on an item, Functional Developer opens the appropriate source file in an editor window, and positions the insertion point at the line containing the problem. If the problem spans a range of lines, the entire range is highlighted in the editor. Likewise, if the problem is an undefined binding, the binding in question is highlighted.

: 2. Double-click on the same item.
: An editor window appears.

Notice how the editor separates each definition in a source file with a gray line. Printed in the middle of each line is the name of the definition below it. These code separators also appear above top-level expressions wrapped with begin ... end.

The code separators are just a visual aid, and are not part of the file itself. If you opened the source file in a different editor you would not see the separators. They are ignored by the compiler.

When you add a new definition, or a new begin ... end top-level form, the code separators will only be updated if you manually refresh the editor window (View > Refresh), move the cursor past an existing separator, or perform some other operation that forces the editor to redisplay.

Figure 2.2 The Functional Developer editor.

Now we can see the cause of the first serious warning. A semi-colon is missing from the end of the definition of number-for-piece in saving.dylan. The missing semi-colon makes the definitions of number-for-piece and piece-for-number run into one another instead of being separate.

As it turns out, all the other serious warnings that were reported were caused by this single missing semi-colon. The compiler could not parse the definitions of number-for-piece and piece-for-number. The compiler skips over such source code and does not generate object code for it.

This means that any subsequent references to number-for-piece and piece-for-number in the source code would be references to name bindings that are never defined in the compiled application. Lines 32, 50, 59, and 73 referred to one or the other of these names, which triggered the serious warnings.

: 3. Add the missing semi-colon so that the last line of the definition number-for-piece appears as follows:

  end method number-for-piece;

While we are editing the file, we can fix the non-serious warning. It is caused by a mismatched end clause in reversi-game-write-data. It is a method, but the end clause says end class instead of end method.

: 4. Locate the definition of the reversi-game-write-data method in saving.dylan.
: 5. Change the last line of the definition so that it appears as follows:

  end method reversi-game-write-data;

: 6. Choose File > Save in the editor.
: Functional Developer saves the file, first making a backup of the previous version in saving.dylan~--that is, in a file of the same name, but with an extra character in the file extension, a tilde (~), to show that it is a backup file.

Having attended to the cause of the serious warnings and warnings, we can rebuild the application and try out the new version.

: 7. Choose Project > Build.
: You can choose this in either the editor or the project window.

Notice the status bar in the Reversi project window after the build is complete:

Build completed with no warnings.

As well as removing the serious warning our semi-colon correction addressed, all the other serious warnings that were follow-on effects of the missing semi-colon have gone away. In addition, the single ordinary warning was removed by the end-clause fix.