Re: fortran support
"Martin Stein" <[email protected]> Tue, 20 Jan 2015 08:31:13 +0100
| Newsgroups | gmane.emacs.cedet |
|---|---|
| Message-ID | <trinity-a0c8bbb7-5581-49f3-af6a-3f9c77070724-1421739073668@3capp-gmx-bs61> |
Hi Fulvio, I am currently working on improving the f90 parser. I will still need a few weeks. The parser is already ported to Wisent, produces much more tags with detailed information on types, dimensions, rank etc. It (hopefully) handles continuation lines properly in all "relevant" cases. However, it is still missing derived-type definitions and declarations, interface blocks and some other stuff. I plan to add preprocessor support (very important to me) later on. I will check your testset as soon as I have a first version. Btw., I am currently investigating the wisent parser with respect to the unmatched syntax cache. I like this feature, but got the impression that it is not intended for general use (more like a debugging feature)? At least there are two issues with wisent in conjunction with EXPAND/EXPANDFULL. If anybody is interested (David Ponce?) to look into these issues I can compose some testcases. (The issues are: (1) Unmatched tokens can end up twice being on the unmatched-syntax-cache [this might be a more serious bug, as this token, stored in wisent-lookahead, can possibly also corrupt the parsing one step up the recursive call chain by the EXPAND(FULL) macro in some rather rare cases, my solution save wisent-lookahead in a local variable just before funcalling the semantic action, then restore it immediately afterwards, I can provide a patch]. (2) Tokens already matched in a partially matched rule which fails the parser are not pushed onto the unmatched-syntax check, the "if (eq (caar la-elt) wisent-lookahead)" can not catch those errors, but I still do not understand the details. [more generally it seems strange that within EXPANDFULL expansion the wisent-parse-stream function is bound and intended to fail after it has matched the rule and successfully parsed part of the stream, because it always expects a $EOI, there are two extra states in automaton - the last two - just to match against $EOI and move the automaton into 'accept state; it feels like there should be a different set of final transitions for rules intended in expandfull macros? On the other it might be easily possible to inject a $EOI token into the lexer stream by the action of a rule just matched, I still need to try this out.]) Martin PS: I already sent a similar version twice yesterday, but it seems to be blocked somewhere on the route?? I try sending it once more. Hopefully I do not spam the list unintentionally. ------------------------------------------------------------------------------ New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet _______________________________________________ Cedet-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/cedet-devel