昨日言及された問題は解決されたようです。今日は、BLOCK DATA プログラム単位の解析に少し取り組みました。これには、新しい解析サブルーチンを parse.c に追加することと check_conflict、これらのプログラム ユニットで見つかった不正な属性について警告するためのロジックが含まれていました。これをテストする機会はまだありません。今日、FSF からいくつかの電子メールを受け取りました。彼らは著作権譲渡フォームを受け取りました。
ジョセフ・サーマック
キャサリン・ヘドストロム
ウィリアム・C・ウェンドリング・ジュニア
ようこそ!
7月18日
行の折り返しに関しては、制御下に戻ったと思います。私の論文プロジェクトは問題なく解析され、私が知る限り、すべてが再び機能します。FORMATステートメントの問題を修正することから始めましたが、今日は時間がなくなりました。
7月17日
わかりました、行を自動的に進めなかった理由を思い出しました。問題は、行に途中で終了する何か (式など) がある場合、エラーの次の行を指すエラーが生成されることです。他の誰かがこの道を再び進むのを防ぐために、戦略的な場所にコメントを入れました。
この種のシーソーは悪い兆候です。それは、先に進む前に十分に考えていなかったことを意味します。残念ながら、失敗したエラー箇所は、マスクされたパーサーの問題よりも重要であるため、再び逆になります。コードは現在コンパイルされていますが、奇妙な場所で奇妙なエラーが生成されます。
FORMAT ステートメントの後のステートメントの末尾が一致しないという問題について、Bertrand Joël に書き込みました。修正は待つ必要があります。
7月16日
今日はメールのやり取り。Tobi は、派生型の typespec に存在するランダムな種類のデータに関係する問題を報告しました。問題は解決したと思いますが、彼のテスト ケースがありません。
Tobi も に発現軌跡を設定するパッチを送ってくれました g95_match_rvalue。彼はまた、引数のないサブルーチンへの CALL が正しく認識されないバグを発見しました。その理由は、ステートメントの終わりを 2 回一致させることに関係していました。g95 の一致規則の 1 つは、何かを一致させると、スキャナは一致したもののすぐ後ろを指すというものです。
EOS が 2 回一致した理由は、g95 のスキャナが、完全なステートメントの一致の間に実行される明示的な呼び出しなしでは次の行に移動しないためです。
もともと、これは物事をより明確にするために行われましたが、今では、これがより高いレベルのサブルーチンの解析バグを覆い隠す状況につながることは明らかです。今日の残りの作業は、g95 でこの不具合を取り除くことに費やしました。
現在、スキャナは行末に達すると ‘\n’ を返し (改行は実際には保存されません)、自動的に次の行に移動します。以前と同様に、ファイルの終わりは改行の無限ストリームを返します。
これにより、コメントをスキップするサブルーチンを 1 つ追加する機会が得られました。これは、特別なコメントの形式でディレクティブを実装する必要がある場合に役立ちます。サブルーチンがアップグレードされ、 g95_match_eos()複数のセミコロンが存在する場合に一致するようになり、コメントのスキップに関連するいくつかのバグが削除されました。
私はg95_next_char、以下が正しく機能していることを確信していますg95_next_statement.