0

I have been trying to solve this issue related to a current school assignment and would highly appreciate if anyone could explain to my why I am getting warnings from my compiler such as decafast.y:201.13-16: warning: rule useless in grammar [-Wother] | Type.

I have provided my code in the two following pastebin files:

decafast.lex: https://pastebin.com/2qzG2cwW
decafast.y: https://pastebin.com/Akg5ehW1

I have also been provided with a file 'decafast.cc' that contains classes and methods that enable me to create lists (I believe that is the purpose), found at:

https://pastebin.com/M7XRJunL

and the specification that I am supposed to follow (grammar found at bottom of page):

http://anoopsarkar.github.io/compilers-class/decafspec.html

My main concern is why I seem to be getting these warnings that are (what I assume to be) causing my code to fail. Nearly every (if not all) of my grammar is deemed to be useless, and despite my online searching (or lack thereof of understanding what has been said already), I am still unsuccessful.

I also had a secondary question if anyone is able to enlighten me. Regarding the .cc file above, I have been given a few classes that implement the decafAST class. In my parser generator file (decafast.y), I attempt to create lists by doing something along the lines of

decafStmtList *s = new decafStmtList();

I assumed that this would allow me to use the push_back() and push_front() methods, which is why I try things such as (in the case of ident_list, line 94) if I see one T_ID, then I create the list for T_ID (identifiers) and push the current T_ID into the list. If I see a situation of ident_list T_COMMA T_ID (which is what I assumed to be the case of a recurring list of comma-separated identifiers), then I would recognize that as an ident_list pattern, and thus push that T_ID into the list as well. Is this the correct way to use the lists that I have been provided?

I would like to stress that as this is an assignment question, I am pleading for any help that you can provide that will allow me to learn on my own terms. I am certain that the users on this website would easily be able to solve this assignment, therefore I would very highly appreciate any insight that you may be able to offer without giving me explicit answers. Thank you all for your time!

Solezano
  • 15
  • 4
  • Add the -v flag to yacc. It will generated more detailed explanation of the error: http://heirloom.sourceforge.net/devtools/yacc.1.html – Martin York Oct 17 '20 at 06:40

2 Answers2

1

The grammar you were provided starts with:

Program = Externs package identifier "{" FieldDecls MethodDecls "}" .

That is, a Program consists of:

  • A possibly empty list of external declarations (library functions used)
  • The keyword "package"
  • An identifier
  • An open brace
  • A possibly empty list of field declarations
  • A possibly empty list of method declarations
  • A close brace.

Most of the rest of the grammar defines what field and method declarations look like, although a couple of productions define external declarations.

But your grammar is quite different: (I removed the actions because they aren't relevant to the grammar)

start: program
program: extern_list decafpackage
extern_list: 
    | ExternDefn
decafpackage: T_PACKAGE T_ID T_LCB T_RCB

Your decafpackage consists only of package ID { }, with nothing between the braces.

So most of the rest of the grammar productions, which detail field amd method declarations, can never be used, making them useless.

(Also, your extern_list does not define a list of ExternDecl. It defines an optional ExternDecl. I think you made that same mistake in other list productions.)

rici
  • 234,347
  • 28
  • 237
  • 341
  • I thought that the { } notation was used to express "0 to n" expressions? If Externs = { ExternDefn }, would this not mean that Externs (a.k.a extern_list) would represent a list of 0 (or more, up to n) ExternDefn's? Thank you for all of your help thus far. – Solezano Oct 17 '20 at 23:02
  • @Solezano: that's exactly what I said: "A possibly empty list of external declarations". But that's not what your `extern_list` produces. – rici Oct 17 '20 at 23:15
  • I apologize for not reading your response thoroughly. I do have one concern still however, which relates to the following situation: In the given FieldDecls definition: FieldDecls = { FieldDecl }, FieldDecl itself can be of three statements, two of which include an { identifier }+, . Does this mean that I must create a list to represent FieldDecls, which will contain a list of FieldDecl, and a list for identifiers which will be 'stored' by FieldDecl? If I were to make these lists, they must be of type decafAST* (to be given access to the push_back() method in .cc), but my tokens hold string – Solezano Oct 17 '20 at 23:40
  • Once again, I would like to extend my thanks to you for taking the time to explain these concepts to me. My goal is to learn, however I am just finding it somewhat difficult to navigate this assignment, therefore I am extremely grateful for your assistance. – Solezano Oct 17 '20 at 23:42
  • Since you don't have the vatiabke type while you're parsing the list of identifiers, you will need to create some data type for that list. So you'll need to figure out an appropriate type. There are loads of possibilities and it doesn't make much difference. It's also possible to modify the grammar using right-recursion to defer the reduction until the type is known, making it possible to desugar the declaration of a list of identifiers into a list of declarations of a single identifier each. But you're late with this assignment, so you should probably choose the simplest option... – rici Oct 18 '20 at 00:02
  • The provided code doesn't spell out any concrete AST classes, and you'll certainly need some. So if you need one more for declaration of a list of identifiers, I can't see why that would raise any eyebrows. – rici Oct 18 '20 at 00:06
-1

The syntax for a bison rule is: result: components…;

As far as I see none of your rules have the semicolon.

SoronelHaetir
  • 14,104
  • 1
  • 12
  • 23