Объяснение и решение для предупреждения JavaCC “Выбора регулярного выражения: НЕЧТО никогда не может подбираться как: ПАНЕЛЬ”?
Необходимость восстановления после истечения срока действия профиля обеспечения зависит от того, как вы распространяете свои приложения.
Если вы следуете передовым методам и используете MDM для распространения своих приложений, вы можете распространять новый профиль обеспечения по истечении срока действия старого.
Если вы используете какой-либо другой метод распространения (например, простой веб-сервер), вам нужно будет перестроить свои приложения после истечения срока действия профиля обеспечения.
Независимо от способа распространения вам необходимо создать новую версию и обновить установленные приложения по истечении срока действия сертификата распространения.
Если срок действия сертификата распространения истекает, приложение перестает работать, даже если профиль обеспечения все еще действителен.
Необходимо обновить приложение новой версией, подписанной новым сертификатом распространения, до истечения срока действия старого.
Этот сеанс WWDC имеет хорошее объяснение этого процесса.
4 ответа
I don't know JavaCC, but I am a compiler engineer.
The FLOAT_PAIR rule is ambiguous. Consider the following text:
0.0
This could be FLOAT 0 followed by FLOAT .0; or it could be FLOAT 0. followed by FLOAT 0; both resulting in FLOAT_PAIR. Or it could be a single FLOAT 0.0.
More importantly, though, you are using lexical analysis with composition in a way that is never likely to work. Consider this number:
12345
This could be parsed as INTEGER 12, INTEGER 345 resulting in an INTEGER_PAIR. Or it could be parsed as INTEGER 123, INTEGER 45, another INTEGER_PAIR. Or it could be INTEGER 12345, another token. The problem exists because you are not requiring white space between the lexical elements of the INTEGER_PAIR (or FLOAT_PAIR).
You should almost never try to handle pairs like this in the lexer. Instead, you should handle plain numbers (INTEGER and FLOAT) as tokens, and handle things like negation and pairing in the parser, where whitespace has been dealt with and stripped.
(For example, how are you going to process "----42"? This is a valid expression in most programming languages, which will correctly calculate multiple negations, but would not be handled by your lexer.)
Also, be aware that single-digit integers in your lexer will not be matched as INTEGER, they will come out as DIGIT. I don't know the correct syntax for JavaCC to fix that for you, though. What you want is to define DIGIT not as a token, but simply something you can use in the definitions of other tokens; alternatively, embed the definition of DIGIT ([0-9]) directly wherever you are using DIGIT in your rules.
Я не использовал JavaCC, но возможно, что NUMBER_PAIR является неоднозначным.
Я думаю, что проблема сводится к тому, что одна и та же вещь может совпадать как с FLOAT_PAIR, так и с INTEGER_PAIR, поскольку FLOAT может соответствовать INTEGER.
Но это всего лишь предположение, никогда не видевшее синтаксиса JavaCC :)
It probably means that for every FLOAT_PAIR you'll just get a FLOAT_PAIR token, never a NUMBER_PAIR token. The FLOAT_PAIR rule already matches all the input and JavaCC will not try to find further matching rules. That would be my interpretation, but I don't know JavaCC, so take it with a grain of salt.
Maybe you can specify somehow that NUMBER_PAIR is the main production and that you don't want to get any other tokens as results.
Благодаря ответу Барри Келли я пришел к следующему решению:
SKIP : { < #TO_SKIP : " " | "\t" > }
TOKEN : { < #DIGIT : (["0"-"9"]) > }
TOKEN : { < #DIGITS : (<DIGIT>)+ > }
TOKEN : { < INTEGER : <DIGITS> > }
TOKEN : { < INTEGER_PAIR : (<INTEGER>) (<TO_SKIP>)+ (<INTEGER>) > }
TOKEN : { < FLOAT : (<NEGATE>)?<DIGITS>"."<DIGITS> | (<NEGATE>)?"."<DIGITS> > }
TOKEN : { < FLOAT_PAIR : (<FLOAT>) (<TO_SKIP>)+ (<FLOAT>) > }
TOKEN : { < #NUMBER : <FLOAT> | <INTEGER> > }
TOKEN : { < NUMBER_PAIR : (<NUMBER>) (<TO_SKIP>)+ (<NUMBER>) >}
TOKEN : { < NEGATE : "-" > }
Я совершенно забыл включить пробел, который используется для разделения двух токенов, я также используется символ «#», который останавливает сопоставление токенов и просто используется в определении других токенов. Вышеупомянутое компилируется JavaCC без предупреждения или ошибки.
Однако, как отметил Барри, есть причины против этого.