No. If you look below the LValue declaration, you'll quickly realize that the LValue class is really there to be subclassed. You shouldn't try to construct a standalone LValue instance. Instead you should create instances of FieldAccess or ArrayAccess.

Rather than creating a new Type object for each and every integer, double, boolean, and string constant, you should use Type::intType, Type::doubleType, Type::boolType, and Type::stringType. If you look at the .cc file, you'll notice that each one of them is prepared at load time to be the very thing you need. Sure, all of integer constants reference the same exact static variable, but that's totally fine, since we don't have you store the value of the integer inside. We minimize the number of type objects, and you'll see that we greatly simplify type checking come PP3.

Yes. Assuming you are in the directory where your project gets built, first start the debugger with gdb ./dcc. Then, once gdb starts up, enter run < tests/samples-pp2/bad1.decaf at the command prompt, for instance.

We don't expect much at all. We just want to see proof that you taught yourself enough about bison's error checking functionality and the error pseudotoken to recover from trivial parsing errors instead of just quitting. Feel free to change the implementation of the supplied yyerror function, but make sure you set $$ equal to something if at all possible, so that bogus yylvals don't get placed on the parser stack only to cause problems later on.

You're free to use it if you want to, but it's actually in the code base for PP3 and beyond. When we detect type incompatibilities during semantic analysis, we'll attach the errorType to the confused expression, and let the errorType propagate up the parse tree to advertise to parent nodes that type issues were found below.