2011-07-13 12 views
0

私はXTextでプリプロセッサ命令のルールを書こうとしています。現在、私はこの方法のようにそれを実装:XTEXT:プリプロセッサ命令のルール

preproc: 
    type=PREPROCESSOR_INCLUDE_TYPE val=(STRING | PREPROCESSOR_INCLUDE_VAL)| 
    type=PREPROCESSOR_DEFINE_TYPE | 
    type=PREPROCESSOR_SINGLE_PARAM_TYPE val=ID| 
    type=PREPROCESSOR_NONE_PARAM_TYPE 
; 


terminal PREPROCESSOR_INCLUDE_TYPE: '#include'| '#import'; 

terminal PREPROCESSOR_INCLUDE_VAL: ' '+ '<'->'>'; 

terminal PREPROCESSOR_DEFINE_TYPE: '#define' -> '\n'; 

terminal PREPROCESSOR_SINGLE_PARAM_TYPE: '#undef' |'#ifdef' |'#ifndef' |'#pragma'; 

terminal PREPROCESSOR_NONE_PARAM_TYPE: '#else' | '#endif'; 

私は本当にこのソリューションを好きではないが、それは私が試したすべてのものの作品だけです。プリプロセッサの命令のためのルールを書くよりスマートな方法がありますか?

プリプロセッサの命令タイプ(#define)とその値を区別するためにPREPROCESSOR_DEFINE_TYPEルールを分割する方法を教えてください。

おかげで、私はこれらのルールをキャプチャしたいものをたくさん

EDIT

は、典型的なプリプロセッサ命令です。たとえば、次のように持っていいだろう何

#include "fileName" 
#import <fileName> 

#define IDENTIFIER 
#define IDENTIFIER WHATEVER + YOU - WANT ! 

#undef IDENTIFIER 

#else 
#endif 

ラファエロ全て異なる場合に、その値からプリプロセッサタイプを分割することです。

+0

具体的な構文の例をいくつか記述してください。少なくともこの文法の断片では、何を達成したいのか分かりにくいです。 –

答えて

0

あなたの質問が分かっている場合は、ルールの残りの部分に属性があり、#defineキーワードが含まれていない、定義ルールのASTノードが必要です。

untilルールや可能性否定の問題点(!)ルールはそれは簡単に解決することができませんでしたので、彼らは、#defineと命令の間に空白文字との競合を引き起こしていること、です。

ただし、新しい端末を定義することができます。

PREPROCESSOR_DEFINE_TYPE: '#define' instruction=Content 
; 

terminal Content: 
    ('a'..'z'|'A'..'Z'|'_') -> '\n' 
; 

が、私は解決策をテストしていないが、それは私のXtextエディタでエラーをスローしない、とある:あなたの言語に追加することができ改行と文字や_、および終了、と、何かが次のようにTerminals.xtextからのIDパラメータの定義と非常によく似ていますので、必要なものに近いはずです。

また、すべてのプリプロセッサタイプをターミナルとして定義する必要はないと思います。このように、低レベルの構造になります。私は可能な限り非終端のルールとしてそれらを定義します。

+1

私はあなたのソリューションを試しましたが、端末のコンテンツはIDなどの他の端末も捕まえてしまい、エディタが正しく動作しません。 – hara

+0

正しく動作しないサンプルをどこかに投稿できますか?おそらくあなたは正しいですが、解決策はそれに近いものでなければならないと私は信じています。 –

1

基本的には、XTextで前処理する言語を作成することはできません。 XTextは1つの文法のコードを生成します。前処理には2つのフィッティング文法が必要です。ここで

課題 http://www.eclipse.org/forums/index.php/mv/msg/366839/894493/#msg_894493

は、念のためだと思うされています

a = 1 
#ifdef something 
    +1 
#endif 
; 

だから、それ故にXTEXTで、それは非現実的になり、1つの文法で、これらすべてを表現することは非常に非効率的です。だから、Cのような多段階言語のサポートがなければ、makeはその範囲外です。