Reported by: pj
Tested by: murf
(closes issue #13416)
Reported by: yarns
Tested by: murf
If you find this message overly verbose, relax, it's probably
not meant for you. This message is meant for probably only
two people in the whole world: me, or the poor schnook that
has to maintain this code because I'm either dead or unavailable
at the moment.
This fix solves two reports, both having to do with embedding
a function call in a ${} construct. It was tricky because the
funccall syntax has parenthesis () in it. And up till now,
the 'word' token in the flex stuff didn't allow that, because
it would tend to steal the LP and RP tokens. To be truthful,
the "word" token was the trickiest, most unstable thing in
the whole lexer. I was lucky it made this long without complaints.
I had to choose every character in the pattern with extreme
care, and I knew that someday I'd have to revisit it. Well,
the day has come.
So, my brilliant idea (and I'm being modest), was to use the
surrounding ${} construct to make a state machine and capture
everything in it, no matter what it contains. But, I have to now
treat the word token like I did with comments, in that I turn
the whole thing into a state-machine sort of spec, with new
contexts "curlystate", "wordstate", and "brackstate".
Wait a minute, "brackstate"? Yes, well, it didn't take very many
regression tests to point out if I do this for ${} constructs,
I also have to do it with the $[] constructs, too.
I had to create a separate pcbstack2 and pcbstack3 because
these constructs can occur inside macro argument lists, and
when we have two state machines operating on the same structures
we'd get problems otherwise. I guess I could have stopped at
pcbstack2 and had the brackstate stuff share it, but it doesn't
hurt to be safe. So, the pcbpush and pcbpop routines also now
have versions for "2" and "3".
I had to add the {KEYWORD} construct to the initial pattern for
"word", because previously word would match stuff like "default7",
because it was a longer match than the keyword "default". But,
not any more, because the word pattern only matches only one or
two characters now, and it will always lose. So, I made it the
winner again by making an optional match on any of the keywords
before it's normal pattern.
I added another regression test to make sure we don't
lose this in future edits, and had to fix just one regression,
where it no longer reports a 'cascaded' error, which I guess
is a plus.
I've given some thought as to whether to apply these fixes to
1.4 and the 1.6.x releases, vs trunk; I decided to put it in
1.4 because one of the bug reports was against 1.4; and it
is unexpected that AEL cannot handle this situation. It actually
reduced the amount of useless "cascade" error messages that
appeared in the regressions (by one line, ehhem). There is
a possible side-effect in that it does now do more careful
checking of what's in those ${} constructs, as far as matching
parens, and brackets are concerned. Some users may find a an
insidious problem and correct it this way. This should be
exceedingly rare, I hope.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@141094 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: korihor
Wow, this one was a challenge!
I regrouped and ran a new strategy for
setting the ~~MACRO~~ value; I set it once
per extension, up near the top. It is only
set if there is a switch in the extension.
So, I had to put in a chunk of code to detect
a switch in the pval tree.
I moved the code to insert the set of ~~exten~~
up to the beginning of the gen_prios routine,
instead of down in the switch code.
I learned that I have to push the detection
of the switches down into the code, so everywhere
I create a new exten in gen_prios, I make sure
to pass onto it the values of the mother_exten
first, and the exten next.
I had to add a couple fields to the exten
struct to accomplish this, in the ael_structs.h
file. The checked field makes it so we don't
repeat the switch search if it's been done.
I also updated the regressions.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@136726 65c4cc65-6c06-0410-ace0-fbb531ad65f3
this for the changes I made to preserve ${EXTEN}
in switches, which affected several tests because
it adds extra priorities, and at least one needed to be updated
because of the removal of the empty extension warning
message.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@119966 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: atis
Many thanks to atis for spotting this problem and reporting it.
The fix was to straighten out how items are placed on and removed
from the file stack. Regressions as well as the provided test case
helped to straighten out all code paths. valgrind was used to make
sure all memory allocated was freed.
Sorry for not solving this earlier. I got distracted.
Added the ntest23 regression test, which is mainly a copy of ntest22,
but with a few juicy errors thrown in, to replicate the kind of
error that atis spotted.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@109309 65c4cc65-6c06-0410-ace0-fbb531ad65f3
1. ael/ael.flex -- the "fix" is here. In short, I modified the
pattern for the chars that break args, to exclude those chars that
would normally break args if they are preceded by a backslash. I did
this to 3 patterns where really, this kind of exclusion should be placed.
2. ael_lex.c is an updated output from lex.
3. the ael-test stuff -- instituted a regression test for this condition.
as ael_ntest9. The "n" in the name means that instead of just getting
the syntax/semantic errors and high-level output from aelparse, we
also want the compilation results to be in the comparison file.
(remove the -n option).
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@37255 65c4cc65-6c06-0410-ace0-fbb531ad65f3
or empty lines are involved;
- change linku1() to return the head of the list (unused at the moment);
- ignore the source line number in runtests as they change with the
source and cause mismatches in the comparison with the reference output.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@23130 65c4cc65-6c06-0410-ace0-fbb531ad65f3
