package pfff

  1. Overview
  2. Docs
Legend:
Page
Library
Module
Module type
Parameter
Class
Class type
Source

Source file token_cpp.ml

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
(* Yoann Padioleau
 *
 * Copyright (C) 2009 University of Urbana Champaign
 *
 * This program is free software; you can redistribute it and/or
 * modify it under the terms of the GNU General Public License (GPL)
 * version 2 as published by the Free Software Foundation.
 * 
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * file license.txt for more details.
 *)

(*****************************************************************************)
(* Prelude *)
(*****************************************************************************)
(* 
 * This file may seem redundant with the tokens generated by Yacc
 * from parser.mly in parser_c.mli. The problem is that we need for
 * many reasons to remember in the AST the tokens involved in the
 * AST, not just the string, especially for the comment and cpp_passed
 * tokens which are not in the AST at all. So,
 * to avoid recursive mutual dependencies, we provide this file
 * so that Ast_cpp does not need to depend on yacc which depends on
 * Ast_cpp, etc. 
 * 
 * Also, ocamlyacc imposes some stupid constraints on the way we can define
 * the token type. ocamlyacc forces us to do a token type that
 * cant be a pair of a sum type, it must be directly a sum type.
 * We don't have this constraint here.
 * 
 * Also, some yacc tokens are not used in the grammar because they are filtered
 * in some intermediate phases. But they still must be declared because
 * ocamllex may generate them, or some intermediate phase may also
 * generate them (like some functions in parsing_hacks.ml).
 * Here we don't have this problem again so we can have a clearer token type.
 * 
 *)

(*****************************************************************************)
(* constructs put in comments in lexer or parsing_hack *)
(*****************************************************************************)

(* 
 * history: was in ast_cpp.ml before:
 *  "This type is not in the Ast but is associated with the TCommentCpp 
 *  token. I put this enum here because parser_c.mly needs it. I could 
 *  have put it also in lexer_parser."
 * 
 * update: now in token_cpp.ml, and actually right now we want those tokens
 * to be in the AST so that in the matching/transforming of C code, we
 * can detect if some metavariables match code which have some
 * cpp_passed tokens next to them (and so where we should issue a warning).
 *)
type cppcommentkind = 
  | CppDirective 
  | CppAttr 
  | CppMacro 
  | CppMacroExpanded
  | CppPassingNormal (* ifdef 0, cplusplus, etc *) 
  | CppPassingCosWouldGetError (* expr passsing *)
(* TODO  | CppPassingExplicit (* skip_start/end tag *) instead of CppOther? *)
  | CppOther

(* at some point we are supposed to also parse those constructs *)
type cpluspluscommentkind =
  | CplusplusTemplate
  | CplusplusQualifier

(*****************************************************************************)
(* Types *)
(*****************************************************************************)
OCaml

Innovation. Community. Security.