This is my attempt to collate and explain the most common errors and warnings you get when compiling code for the Arduino and Arduino-like boards.
Errors
Expected primary expression before '.' token
This is usually because you used a class name instead of an instance of a class. One example would be if you created an instance of the LiquidCrystal class:
LiquidCrystal lcd(4, 5, 6, 7, 8, 9, 10);
And then used something like:
LiquidCrystal.print("foo");
instead of:
lcd.print("foo");
Stray '\' in program
This one can be tricky to track down. It's often seen when you are trying to embed quotes within a string literal. Escaping the quotes means putting \ infront of them, for example: "He said \"Hello\"". Getting the escapes in the right order can be both tricky and hard to notice when you have it wrong. For example "He said \"Hello"\" looks almost the same, but is wrong.
Stray '\302' in program
This is slightly different to the above error. The 302 may be different numbers. It is caused when you have international characters in your code (comments don't count). The biggest cause is when you copy and paste code from a website which has changed the basic quotes " into fancy ones like “ and ”
multiple definition of '__vector_XX'
A vector is one of the built in interrupt routines with the Arduino. It's the part of the software where other code "hooks in" to be executed when a certain interrupt is triggered. Your problem here is that you have two libraries or pieces of code that both want to hook in to the same place. That can't happen. The Servo library is a common culprit.
Warnings
ISO C++ forbids converting a string constant to 'char*'
In C a string can be either "constant" or "variable". A string literal (that is, anything written directly in quotes) is a constant. If you pass that to a function that expects a variable it complains. The problem here is that a string constant (identified as const char *) will not be modified by the function (indeed, the compiler won't allow it). But a string variable (just char *) can be modified by a function. If you pass a string literal, which being a literal block of characters in your code cannot be modified, to a function that has the potential to modify the string you pass to it, horrible things could happen. This is most often seen when the author of a library doesn't understand these subtleties. So rule one of writing functions that take C strings is: if you aren't going to be modifying the data then make sure you have it as const char *.
You can pass a char * to a function that expects a const char *, but you shouldn't pass a const char * to a function that expects a char *. So there's no harm in making it const unless you really do want to modify the string data.
Variable 'x' set but not used
This is pretty innocuous. It's just telling you that at some point you created a variable and assigned a value to it. But then you never used it for anything. The compiler will optimise away that variable, so it will no longer exist, which is fine - it's just letting you know in case you happened to have made a typing error somewhere...
Narrowing conversion of 'x' from 'int' to 'byte'
This is because you are trying to stuff more data into a variable that it can hold. Int and byte can be other data types, of course. In the example I show just above it's warning you that you are trying to copy a 16 (or 32-bit on a 32-bit MCU) value into an 8-bit variable. It just can't fit. You can also see the same or similar warnings when you try and copy between signed and unsigned variables of the same size. If you know that what you are doing is correct you can hide the warning by casting the source variable: byte b = (byte)i; (where i is int).
Left shift count >= width of type
Commonly seen when a library has been written to work on a 32-bit system and has used types without a guaranteed size. If you try and left shift a value (using <<) more than the number of bits that there are in the variable type then it warns you. The results are undefined. A good example is when code was written to work on a 32-bit MCU using the int type, which is 32-bits in size. Shifting the value 20 bits to the left in this case is perfectly fine. But then the same library is compiled on an 8-bit system where the int data type is only 16 bits. Shifting the value 20 bits to the left in this case makes no sense. The cure is to never use int - instead use the fixed size variable types of int32_t, uint16_t etc.