This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 149968 - better lexing error recovery
Summary: better lexing error recovery
Status: RESOLVED WONTFIX
Alias: None
Product: editor
Classification: Unclassified
Component: Lexer (show other bugs)
Version: 6.x
Hardware: All All
: P3 blocker (vote)
Assignee: Miloslav Metelka
URL:
Keywords:
: 162492 167860 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-10-13 16:32 UTC by Marek Fukala
Modified: 2012-11-08 09:07 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Marek Fukala 2008-10-13 16:32:46 UTC
In templating languages it is common to generate attribute values like this: <body align=<%="center"%> valign="top"/>

However html lexer just sees <body align= valign="top"/> and stops lexing after the first equals sign. Better would be
to reset to "in tag" state and then use some semantic error to indicate the missing value.
Comment 1 Marek Fukala 2009-04-21 11:04:10 UTC
Another example from issue #162841 is: <div <%="..."%> />. The resulting html virtual source is <div @@@/> which the
html lexer doesn't accept hence the parse tree is broken (and the users are unhappy about false warnings in the source).
Comment 2 Marek Fukala 2009-04-21 11:05:17 UTC
Another example from issue #162841 is: <div <%="..."%> />. The resulting html virtual source is <div @@@/> which the
html lexer doesn't accept hence the parse tree is broken (and the users are unhappy about false warnings in the source).
I'll try to fix this into nb6.7
Comment 3 Marek Fukala 2009-04-21 11:06:15 UTC
*** Issue 162492 has been marked as a duplicate of this issue. ***
Comment 4 Marek Fukala 2009-08-19 08:50:22 UTC
*** Issue 167860 has been marked as a duplicate of this issue. ***
Comment 5 Marek Fukala 2009-11-02 13:19:15 UTC
fixed in web-main#4c1659cc0926

Comment 6 Quality Engineering 2009-11-03 10:24:00 UTC
Integrated into 'main-golden', will be available in build *200911030222* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/4c1659cc0926
User: Marek Fukala <mfukala@netbeans.org>
Log: #149968 - better lexing error recovery
Comment 7 olemasor 2010-01-29 06:15:38 UTC
I have got NB6.7.1 build:200911211148, but there still seems to be a problem with sentences like this:

<input type="radio" name="mode" value="all" <?= ($_SESSION['mode']==='all') ? 'checked' :'' ?> />

I get the error: "Missing required end tag".
If I write:

<input type="radio" name="mode" value="all" checked="<?= ($_SESSION['mode']==='all') ? 'checked' :'' ?>" />

instead, then no error is reported, but then ofcourse I loose the functionality which was the reason for putting the php-bit in there.

*to sum up:
<emptytag <?= ?> /> reports "missing end tag" error but shouldn't
<emptytag att="<?= ?>" /> does not report error, which is ok
Comment 8 Marek Fukala 2010-02-01 02:34:08 UTC
I'm aware of the <emptytag att="<?= ?>" issue. It is supposed to be filed as an issue somwhere, but I cannot find it now. There's a unit test for this usecase as well. in CssParserTest. I'll duplicate it once I find the original issue. Thanks for your time.
Comment 9 Marek Fukala 2010-04-20 14:14:45 UTC
I've tried following cases (in s JSP) in latest dev build:

OK:
        <div align="<%="center"%>" class="Bordered"/>
        <input type="radio" name="mode" value="all" <%= "" %> />

Fails (the text after templating is lexed as attribute value):
        <div align=<%="center"%> valign="top"/>
Comment 10 Marek Fukala 2010-04-26 15:54:51 UTC
The case <div align=<%="center"%> valign="top"/> is little harder to fix since the html lexer sees just the html code, not the templating:

     <div align= valign="top"/>
Comment 11 Marek Fukala 2010-04-28 09:15:16 UTC
There needs to be some kind of possibility to check if the char read from the lexer input directly preceedes the previous char or if there's a gap. 

I could imagine a new method:

boolean LexerInput.readCharAfterGap();

which the lexer could use to optimize the behaviour in the kind of situations described above.
Comment 12 Marek Fukala 2010-12-09 15:02:42 UTC
Milo, possibly close as won't fix if it is not doable or too much work. Thanks.
Comment 13 David Strupl 2012-11-08 09:07:27 UTC
Closing some old Mila's bugs.