Bison warnings
Bug #1776089 reported by
Chad Parker
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
pcb |
Fix Released
|
Low
|
Chad Parker |
Bug Description
There are three bison warnings when master (as of 20180610)
/home/cparker/
/home/cparker/
/home/cparker/
%name-prefix="res"
^^^^^^^^^^^^^
The first two I'm confused about how to fix. The problem is indicated to be with state 0.
The third one is easy. Replace the = with a <space>.
Changed in pcb: | |
importance: | Undecided → Low |
status: | New → In Progress |
Changed in pcb: | |
milestone: | none → pcb-4.2.0 |
Changed in pcb: | |
assignee: | nobody → Chad Parker (parker-charles) |
Changed in pcb: | |
milestone: | pcb-4.2.0 → pcb-4.1.3 |
Changed in pcb: | |
status: | Fix Committed → Fix Released |
To post a comment you must log in.
Okay, I managed to fix the bison warnings. Branch: LP1776089
This took a while to figure out. One issue had to do with the path for loading elements to a buffer. If "Element" is the first thing in a file, either of these could be valid parse paths:
parse -> parsepcb -> element
or
parse -> parsedata -> pcbdata -> pcbdefinitions -> pcbdefinition -> element
The first was intended for parsing element files, the second for parsing elements in pcb files or "data" files.
I've fixed this by removing the first path, and merging it with the second path. There's a new variable file_type that is an enumerated type that is set depending on the type of file being parsed. The second path now checks that variable and parses the element data appropriately.
The other conflict was similar. There were two paths to "error".
parse -> error
or
parse -> parsedata -> pcbdata -> pcbdefinitions -> pcbdefinition -> error
I fixed this by deleting the second path. This could be used for error recovery, but, our error recovery strategy is presently to abort, it doesn't really do anything anyway. A syntax error is still reported and the load is aborted.