Add poc files

lang_cpp/parsing/conflicts.txt

@@ -0,0 +1,93 @@
+-*- org -*-
+
+TODO:
+http://blog.robertelder.org/jim-roskind-grammar/
+
+http://eli.thegreenplace.net/2007/11/24/the-context-sensitivity-of-cs-grammar/
+
+* Typedefs 
+
+simple_type_specifier:
+ ...
+ | type_cplusplus_id { Right3 (TypeName $1), noii }
+
+ (* history: cant put TIdent {} cos it makes the grammar ambiguous and 
+  * generates lots of conflicts => we must use some tricks. 
+  * We used make the lexer and parser cooperate (in a lexerParser.ml file).
+  * But this was not enough because of declarations such as 'acpi acpi;'
+  * and so we had to enable/disable the ident->typedef mechanism 
+  * (which requires even more lexer/parser cooperation). But
+  * this was ugly too so now we use a typedef "inference" mechanism.
+
+We do many things to handle typedefs ambiguities:
+ - parsing_hack_typedef heuristics
+ - token_view_context in Parameter heuristics
+ - dealing with template before the actual typedef
+ - a few rules added for parameter and arguments to allow
+   both TIdent and TIdent_typedef in both contexts
+ - ...
+
+
+** pointer decl, multiplication and ambiguity
+
+from "Yacc Is Dead" at http://lambda-the-ultimate.org/node/4148#comment
+
+" 'x*y;' in C++ this could be a multiplication, pointer declaration, or
+arbitrary overloaded meaning of "*". You have to hit name and type
+resolution before you can distinguish them."
+
+** cast and ambiguity
+
+can be cast or binary minus
+  (u32int)-pa
+
+can be cast or funcall
+  (u32int)(-pa));
+
+same with (uintptr)&x.
+
+* If-then-else
+
+see dangling-else section in lang_php/parsing/conflicts.txt
+
+* Template < >
+
+We do many things ...
+
+* C++
+
+* TODO ':'
+
+When have 'class X :' we don't know if it's the start of possibly a
+class with inheritance spec, or a bitfield as 'class X :3'.
+
+TODO why have conflict on TCol ???
+
+
+* Old notes
+
+(* Cocci: Each token will be decorated in the future by the mcodekind
+ * of cocci. It is the job of the pretty printer to look at this
+ * information and decide to print or not the token (and also the
+ * pending '+' associated sometimes with the token).
+ * 
+ * The first time that we parse the original C file, the mcodekind is
+ * empty, or more precisely all is tagged as a CONTEXT with NOTHING
+ * associated. This is what I call a "clean" expr/statement/....
+ * 
+ * Each token will also be decorated in the future with an environment,
+ * because the pending '+' may contain metavariables that refer to some
+ * C code.
+ * 
+ * Update: Now I use a ref! so take care.
+ * 
+ * Sometimes we want to add someting at the beginning or at the end 
+ * of a construct. For 'function' and 'decl' we want add something
+ * to their left and for 'if' 'while' et 'for' and so on at their right.
+ * We want some kinds of "virtual placeholders" that represent the start or
+ * end of a construct. We use fakeInfo for that purpose.
+ * To identify those cases I have added a fakestart/fakeend comment.
+ * 
+ * convention: I often use 'ii' for the name of a list of info. 
+ * 
+ *)