ANSIfy cp/parser.c

[Nathanael Nerode]

Bootstrapped on i686-pc-linux-gnu. OK to commit?

I'm doing these one file at a time because they're *huge* (and because I
have to do most of it by hand). I'm asking
for approval because the ANSIfication of the function defintions (the
way formal parameters are specified) doesn't appear to fall under the
'obvious' rule. If someone says it does, I'll start putting these in
as soon as they bootstrap. :-)

* parser.c: ANSIfy function declarations and definitions.

Index: parser.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/cp/parser.c,v
retrieving revision 1.23
diff -u -r1.23 parser.c
--- parser.c 8 Jan 2003 20:00:17 -0000 1.23
+++ parser.c 9 Jan 2003 02:28:18 -0000
@@ -214,53 +214,53 @@
/* Prototypes. */

static cp_lexer *cp_lexer_new
- PARAMS ((bool));
+ (bool);
static cp_lexer *cp_lexer_new_from_tokens
- PARAMS ((struct cp_token_cache *));
+ (struct cp_token_cache *);
static int cp_lexer_saving_tokens
- PARAMS ((const cp_lexer *));
+ (const cp_lexer *);
static cp_token *cp_lexer_next_token
- PARAMS ((cp_lexer *, cp_token *));
-static ptrdiff_t cp_lexer_token_difference
- PARAMS ((cp_lexer *, cp_token *, cp_token *));
+ (cp_lexer *, cp_token *);
+static ptrdiff_t cp_lexer_token_difference
+ (cp_lexer *, cp_token *, cp_token *);
static cp_token *cp_lexer_read_token
- PARAMS ((cp_lexer *));
+ (cp_lexer *);
static void cp_lexer_maybe_grow_buffer
- PARAMS ((cp_lexer *));
+ (cp_lexer *);
static void cp_lexer_get_preprocessor_token
- PARAMS ((cp_lexer *, cp_token *));
+ (cp_lexer *, cp_token *);
static cp_token *cp_lexer_peek_token
- PARAMS ((cp_lexer *));
+ (cp_lexer *);
static cp_token *cp_lexer_peek_nth_token
- PARAMS ((cp_lexer *, size_t));
+ (cp_lexer *, size_t);
static inline bool cp_lexer_next_token_is
- PARAMS ((cp_lexer *, enum cpp_ttype));
+ (cp_lexer *, enum cpp_ttype);
static bool cp_lexer_next_token_is_not
- PARAMS ((cp_lexer *, enum cpp_ttype));
+ (cp_lexer *, enum cpp_ttype);
static bool cp_lexer_next_token_is_keyword
- PARAMS ((cp_lexer *, enum rid));
-static cp_token *cp_lexer_consume_token
- PARAMS ((cp_lexer *));
+ (cp_lexer *, enum rid);
+static cp_token *cp_lexer_consume_token
+ (cp_lexer *);
static void cp_lexer_purge_token
(cp_lexer *);
static void cp_lexer_purge_tokens_after
(cp_lexer *, cp_token *);
static void cp_lexer_save_tokens
- PARAMS ((cp_lexer *));
+ (cp_lexer *);
static void cp_lexer_commit_tokens
- PARAMS ((cp_lexer *));
+ (cp_lexer *);
static void cp_lexer_rollback_tokens
- PARAMS ((cp_lexer *));
+ (cp_lexer *);
static inline void cp_lexer_set_source_position_from_token
- PARAMS ((cp_lexer *, const cp_token *));
+ (cp_lexer *, const cp_token *);
static void cp_lexer_print_token
- PARAMS ((FILE *, cp_token *));
+ (FILE *, cp_token *);
static inline bool cp_lexer_debugging_p
- PARAMS ((cp_lexer *));
+ (cp_lexer *);
static void cp_lexer_start_debugging
- PARAMS ((cp_lexer *)) ATTRIBUTE_UNUSED;
+ (cp_lexer *) ATTRIBUTE_UNUSED;
static void cp_lexer_stop_debugging
- PARAMS ((cp_lexer *)) ATTRIBUTE_UNUSED;
+ (cp_lexer *) ATTRIBUTE_UNUSED;

/* Manifest constants. */

@@ -380,9 +380,8 @@
TOKEN. */

static inline void
-cp_lexer_set_source_position_from_token (lexer, token)
- cp_lexer *lexer ATTRIBUTE_UNUSED;
- const cp_token *token;
+cp_lexer_set_source_position_from_token (cp_lexer *lexer ATTRIBUTE_UNUSED ,
+ const cp_token *token)
{
/* Ideally, the source position information would not be a global
variable, but it is. */
@@ -399,9 +398,7 @@
the next token in the buffer. */

static inline cp_token *
-cp_lexer_next_token (lexer, token)
- cp_lexer *lexer;
- cp_token *token;
+cp_lexer_next_token (cp_lexer* lexer, cp_token* token)
{
token++;
if (token == lexer->buffer_end)
@@ -412,8 +409,7 @@
/* Non-zero if we are presently saving tokens. */

static int
-cp_lexer_saving_tokens (lexer)
- const cp_lexer *lexer;
+cp_lexer_saving_tokens (const cp_lexer* lexer)
{
return VARRAY_ACTIVE_SIZE (lexer->saved_tokens) != 0;
}
@@ -434,10 +430,7 @@
to reach FINISH. If START and FINISH are the same, returns zero. */

static ptrdiff_t
-cp_lexer_token_difference (lexer, start, finish)
- cp_lexer *lexer;
- cp_token *start;
- cp_token *finish;
+cp_lexer_token_difference (cp_lexer* lexer, cp_token* start, cp_token* finish)
{
if (finish >= start)
return finish - start;
@@ -450,8 +443,7 @@
token buffer. Returns the newly read token. */

static cp_token *
-cp_lexer_read_token (lexer)
- cp_lexer *lexer;
+cp_lexer_read_token (cp_lexer* lexer)
{
cp_token *token;

@@ -542,8 +534,7 @@
/* If the circular buffer is full, make it bigger. */

static void
-cp_lexer_maybe_grow_buffer (lexer)
- cp_lexer *lexer;
+cp_lexer_maybe_grow_buffer (cp_lexer* lexer)
{
/* If the buffer is full, enlarge it. */
if (lexer->last_token == lexer->first_token)
@@ -603,9 +594,8 @@
/* Store the next token from the preprocessor in *TOKEN. */

static void
-cp_lexer_get_preprocessor_token (lexer, token)
- cp_lexer *lexer ATTRIBUTE_UNUSED;
- cp_token *token;
+cp_lexer_get_preprocessor_token (cp_lexer *lexer ATTRIBUTE_UNUSED ,
+ cp_token *token)
{
bool done;

@@ -672,8 +662,7 @@
consume it. */

static cp_token *
-cp_lexer_peek_token (lexer)
- cp_lexer *lexer;
+cp_lexer_peek_token (cp_lexer* lexer)
{
cp_token *token;

@@ -697,9 +686,7 @@
/* Return true if the next token has the indicated TYPE. */

static bool
-cp_lexer_next_token_is (lexer, type)
- cp_lexer *lexer;
- enum cpp_ttype type;
+cp_lexer_next_token_is (cp_lexer* lexer, enum cpp_ttype type)
{
cp_token *token;

@@ -712,9 +699,7 @@
/* Return true if the next token does not have the indicated TYPE. */

static bool
-cp_lexer_next_token_is_not (lexer, type)
- cp_lexer *lexer;
- enum cpp_ttype type;
+cp_lexer_next_token_is_not (cp_lexer* lexer, enum cpp_ttype type)
{
return !cp_lexer_next_token_is (lexer, type);
}
@@ -722,9 +707,7 @@
/* Return true if the next token is the indicated KEYWORD. */

static bool
-cp_lexer_next_token_is_keyword (lexer, keyword)
- cp_lexer *lexer;
- enum rid keyword;
+cp_lexer_next_token_is_keyword (cp_lexer* lexer, enum rid keyword)
{
cp_token *token;

@@ -738,9 +721,7 @@
then this is precisely equivalent to cp_lexer_peek_token. */

static cp_token *
-cp_lexer_peek_nth_token (lexer, n)
- cp_lexer *lexer;
- size_t n;
+cp_lexer_peek_nth_token (cp_lexer* lexer, size_t n)
{
cp_token *token;

@@ -775,8 +756,7 @@
time. */

static cp_token *
-cp_lexer_consume_token (lexer)
- cp_lexer *lexer;
+cp_lexer_consume_token (cp_lexer* lexer)
{
cp_token *token;

@@ -883,8 +863,7 @@
preserved. */

static void
-cp_lexer_save_tokens (lexer)
- cp_lexer *lexer;
+cp_lexer_save_tokens (cp_lexer* lexer)
{
/* Provide debugging output. */
if (cp_lexer_debugging_p (lexer))
@@ -904,8 +883,7 @@
/* Commit to the portion of the token stream most recently saved. */

static void
-cp_lexer_commit_tokens (lexer)
- cp_lexer *lexer;
+cp_lexer_commit_tokens (cp_lexer* lexer)
{
/* Provide debugging output. */
if (cp_lexer_debugging_p (lexer))
@@ -918,8 +896,7 @@
to the token stream. Stop saving tokens. */

static void
-cp_lexer_rollback_tokens (lexer)
- cp_lexer *lexer;
+cp_lexer_rollback_tokens (cp_lexer* lexer)
{
size_t delta;

@@ -946,9 +923,7 @@
/* Print a representation of the TOKEN on the STREAM. */

static void
-cp_lexer_print_token (stream, token)
- FILE *stream;
- cp_token *token;
+cp_lexer_print_token (FILE * stream, cp_token* token)
{
const char *token_type = NULL;

@@ -1018,8 +993,7 @@
/* Start emitting debugging information. */

static void
-cp_lexer_start_debugging (lexer)
- cp_lexer *lexer;
+cp_lexer_start_debugging (cp_lexer* lexer)
{
++lexer->debugging_p;
}
@@ -1027,8 +1001,7 @@
/* Stop emitting debugging information. */

static void
-cp_lexer_stop_debugging (lexer)
- cp_lexer *lexer;
+cp_lexer_stop_debugging (cp_lexer* lexer)
{
--lexer->debugging_p;
}
@@ -1205,7 +1178,7 @@
/* Constructors and destructors. */

static cp_parser_context *cp_parser_context_new
- PARAMS ((cp_parser_context *));
+ (cp_parser_context *);

/* Class variables. */

@@ -1217,8 +1190,7 @@
is given by NEXT. */

static cp_parser_context *
-cp_parser_context_new (next)
- cp_parser_context *next;
+cp_parser_context_new (cp_parser_context* next)
{
cp_parser_context *context;

@@ -1356,14 +1328,14 @@
} cp_parser;

/* The type of a function that parses some kind of expression */
-typedef tree (*cp_parser_expression_fn) PARAMS ((cp_parser *));
+typedef tree (*cp_parser_expression_fn) (cp_parser *);

/* Prototypes. */

/* Constructors and destructors. */

static cp_parser *cp_parser_new
- PARAMS ((void));
+ (void);

/* Routines to parse various constructs.

@@ -1380,21 +1352,21 @@
/* Lexical conventions [gram.lex] */

static tree cp_parser_identifier
- PARAMS ((cp_parser *));
+ (cp_parser *);

/* Basic concepts [gram.basic] */

static bool cp_parser_translation_unit
- PARAMS ((cp_parser *));
+ (cp_parser *);

/* Expressions [gram.expr] */

static tree cp_parser_primary_expression
(cp_parser *, cp_parser_id_kind *, tree *);
static tree cp_parser_id_expression
- PARAMS ((cp_parser *, bool, bool, bool *));
+ (cp_parser *, bool, bool, bool *);
static tree cp_parser_unqualified_id
- PARAMS ((cp_parser *, bool, bool));
+ (cp_parser *, bool, bool);
static tree cp_parser_nested_name_specifier_opt
(cp_parser *, bool, bool, bool);
static tree cp_parser_nested_name_specifier
@@ -1404,179 +1376,179 @@
static tree cp_parser_postfix_expression
(cp_parser *, bool);
static tree cp_parser_expression_list
- PARAMS ((cp_parser *));
+ (cp_parser *);
static void cp_parser_pseudo_destructor_name
- PARAMS ((cp_parser *, tree *, tree *));
+ (cp_parser *, tree *, tree *);
static tree cp_parser_unary_expression
(cp_parser *, bool);
static enum tree_code cp_parser_unary_operator
- PARAMS ((cp_token *));
+ (cp_token *);
static tree cp_parser_new_expression
- PARAMS ((cp_parser *));
+ (cp_parser *);
static tree cp_parser_new_placement
- PARAMS ((cp_parser *));
+ (cp_parser *);
static tree cp_parser_new_type_id
- PARAMS ((cp_parser *));
+ (cp_parser *);
static tree cp_parser_new_declarator_opt
- PARAMS ((cp_parser *));
+ (cp_parser *);
static tree cp_parser_direct_new_declarator
- PARAMS ((cp_parser *));
+ (cp_parser *);
static tree cp_parser_new_initializer
- PARAMS ((cp_parser *));
+ (cp_parser *);
static tree cp_parser_delete_expression
- PARAMS ((cp_parser *));
+ (cp_parser *);
static tree cp_parser_cast_expression
(cp_parser *, bool);
static tree cp_parser_pm_expression
- PARAMS ((cp_parser *));
+ (cp_parser *);
static tree cp_parser_multiplicative_expression
- PARAMS ((cp_parser *));
+ (cp_parser *);
static tree cp_parser_additive_expression
- PARAMS ((cp_parser *));
+ (cp_parser *);
static tree cp_parser_shift_expression
- PARAMS ((cp_parser *));
+ (cp_parser *);
static tree cp_parser_relational_expression
- PARAMS ((cp_parser *));
+ (cp_parser *);
static tree cp_parser_equality_expression
- PARAMS ((cp_parser *));
+ (cp_parser *);
static tree cp_parser_and_expression
- PARAMS ((cp_parser *));
+ (cp_parser *);
static tree cp_parser_exclusive_or_expression
- PARAMS ((cp_parser *));
+ (cp_parser *);
static tree cp_parser_inclusive_or_expression
- PARAMS ((cp_parser *));
+ (cp_parser *);
static tree cp_parser_logical_and_expression
- PARAMS ((cp_parser *));
+ (cp_parser *);
static tree cp_parser_logical_or_expression
- PARAMS ((cp_parser *));
+ (cp_parser *);
static tree cp_parser_conditional_expression
- PARAMS ((cp_parser *));
+ (cp_parser *);
static tree cp_parser_question_colon_clause
- PARAMS ((cp_parser *, tree));
+ (cp_parser *, tree);
static tree cp_parser_assignment_expression
- PARAMS ((cp_parser *));
+ (cp_parser *);
static enum tree_code cp_parser_assignment_operator_opt
- PARAMS ((cp_parser *));
+ (cp_parser *);
static tree cp_parser_expression
- PARAMS ((cp_parser *));
+ (cp_parser *);
static tree cp_parser_constant_expression
- PARAMS ((cp_parser *));
+ (cp_parser *);

/* Statements [gram.stmt.stmt] */

static void cp_parser_statement
- PARAMS ((cp_parser *));
+ (cp_parser *);
static tree cp_parser_labeled_statement
- PARAMS ((cp_parser *));
+ (cp_parser *);
static tree cp_parser_expression_statement
- PARAMS ((cp_parser *));
+ (cp_parser *);
static tree cp_parser_compound_statement
(cp_parser *);
static void cp_parser_statement_seq_opt
- PARAMS ((cp_parser *));
+ (cp_parser *);
static tree cp_parser_selection_statement
- PARAMS ((cp_parser *));
+ (cp_parser *);
static tree cp_parser_condition
- PARAMS ((cp_parser *));
+ (cp_parser *);
static tree cp_parser_iteration_statement
- PARAMS ((cp_parser *));
+ (cp_parser *);
static void cp_parser_for_init_statement
- PARAMS ((cp_parser *));
+ (cp_parser *);
static tree cp_parser_jump_statement
- PARAMS ((cp_parser *));
+ (cp_parser *);
static void cp_parser_declaration_statement
- PARAMS ((cp_parser *));
+ (cp_parser *);

static tree cp_parser_implicitly_scoped_statement
- PARAMS ((cp_parser *));
+ (cp_parser *);
static void cp_parser_already_scoped_statement
- PARAMS ((cp_parser *));
+ (cp_parser *);

/* Declarations [gram.dcl.dcl] */

static void cp_parser_declaration_seq_opt
- PARAMS ((cp_parser *));
+ (cp_parser *);
static void cp_parser_declaration
- PARAMS ((cp_parser *));
+ (cp_parser *);
static void cp_parser_block_declaration
- PARAMS ((cp_parser *, bool));
+ (cp_parser *, bool);
static void cp_parser_simple_declaration
- PARAMS ((cp_parser *, bool));
+ (cp_parser *, bool);
static tree cp_parser_decl_specifier_seq
- PARAMS ((cp_parser *, cp_parser_flags, tree *, bool *));
+ (cp_parser *, cp_parser_flags, tree *, bool *);
static tree cp_parser_storage_class_specifier_opt
- PARAMS ((cp_parser *));
+ (cp_parser *);
static tree cp_parser_function_specifier_opt
- PARAMS ((cp_parser *));
+ (cp_parser *);
static tree cp_parser_type_specifier
- (cp_parser *, cp_parser_flags, bool, bool, bool *, bool *);
+ (cp_parser *, cp_parser_flags, bool, bool, bool *, bool *);
static tree cp_parser_simple_type_specifier
- PARAMS ((cp_parser *, cp_parser_flags));
+ (cp_parser *, cp_parser_flags);
static tree cp_parser_type_name
- PARAMS ((cp_parser *));
+ (cp_parser *);
static tree cp_parser_elaborated_type_specifier
- PARAMS ((cp_parser *, bool, bool));
+ (cp_parser *, bool, bool);
static tree cp_parser_enum_specifier
- PARAMS ((cp_parser *));
+ (cp_parser *);
static void cp_parser_enumerator_list
- PARAMS ((cp_parser *, tree));
+ (cp_parser *, tree);
static void cp_parser_enumerator_definition
- PARAMS ((cp_parser *, tree));
+ (cp_parser *, tree);
static tree cp_parser_namespace_name
- PARAMS ((cp_parser *));
+ (cp_parser *);
static void cp_parser_namespace_definition
- PARAMS ((cp_parser *));
+ (cp_parser *);
static void cp_parser_namespace_body
- PARAMS ((cp_parser *));
+ (cp_parser *);
static tree cp_parser_qualified_namespace_specifier
- PARAMS ((cp_parser *));
+ (cp_parser *);
static void cp_parser_namespace_alias_definition
- PARAMS ((cp_parser *));
+ (cp_parser *);
static void cp_parser_using_declaration
- PARAMS ((cp_parser *));
+ (cp_parser *);
static void cp_parser_using_directive
- PARAMS ((cp_parser *));
+ (cp_parser *);
static void cp_parser_asm_definition
- PARAMS ((cp_parser *));
+ (cp_parser *);
static void cp_parser_linkage_specification
- PARAMS ((cp_parser *));
+ (cp_parser *);

/* Declarators [gram.dcl.decl] */

static tree cp_parser_init_declarator
- PARAMS ((cp_parser *, tree, tree, tree, bool, bool, bool *));
+ (cp_parser *, tree, tree, tree, bool, bool, bool *);
static tree cp_parser_declarator
- PARAMS ((cp_parser *, cp_parser_declarator_kind, bool *));
+ (cp_parser *, cp_parser_declarator_kind, bool *);
static tree cp_parser_direct_declarator
- PARAMS ((cp_parser *, cp_parser_declarator_kind, bool *));
+ (cp_parser *, cp_parser_declarator_kind, bool *);
static enum tree_code cp_parser_ptr_operator
- PARAMS ((cp_parser *, tree *, tree *));
+ (cp_parser *, tree *, tree *);
static tree cp_parser_cv_qualifier_seq_opt
- PARAMS ((cp_parser *));
+ (cp_parser *);
static tree cp_parser_cv_qualifier_opt
- PARAMS ((cp_parser *));
+ (cp_parser *);
static tree cp_parser_declarator_id
- PARAMS ((cp_parser *));
+ (cp_parser *);
static tree cp_parser_type_id
- PARAMS ((cp_parser *));
+ (cp_parser *);
static tree cp_parser_type_specifier_seq
- PARAMS ((cp_parser *));
+ (cp_parser *);
static tree cp_parser_parameter_declaration_clause
- PARAMS ((cp_parser *));
+ (cp_parser *);
static tree cp_parser_parameter_declaration_list
- PARAMS ((cp_parser *));
+ (cp_parser *);
static tree cp_parser_parameter_declaration
- PARAMS ((cp_parser *, bool));
+ (cp_parser *, bool);
static tree cp_parser_function_definition
- PARAMS ((cp_parser *, bool *));
+ (cp_parser *, bool *);
static void cp_parser_function_body
(cp_parser *);
static tree cp_parser_initializer
- PARAMS ((cp_parser *, bool *));
+ (cp_parser *, bool *);
static tree cp_parser_initializer_clause
- PARAMS ((cp_parser *));
+ (cp_parser *);
static tree cp_parser_initializer_list
- PARAMS ((cp_parser *));
+ (cp_parser *);

static bool cp_parser_ctor_initializer_opt_and_function_body
(cp_parser *);
@@ -1586,162 +1558,160 @@
static tree cp_parser_class_name
(cp_parser *, bool, bool, bool, bool, bool, bool);
static tree cp_parser_class_specifier
- PARAMS ((cp_parser *));
+ (cp_parser *);
static tree cp_parser_class_head
- PARAMS ((cp_parser *, bool *, bool *, tree *));
+ (cp_parser *, bool *, bool *, tree *);
static enum tag_types cp_parser_class_key
- PARAMS ((cp_parser *));
+ (cp_parser *);
static void cp_parser_member_specification_opt
- PARAMS ((cp_parser *));
+ (cp_parser *);
static void cp_parser_member_declaration
- PARAMS ((cp_parser *));
+ (cp_parser *);
static tree cp_parser_pure_specifier
- PARAMS ((cp_parser *));
+ (cp_parser *);
static tree cp_parser_constant_initializer
- PARAMS ((cp_parser *));
+ (cp_parser *);

/* Derived classes [gram.class.derived] */

static tree cp_parser_base_clause
- PARAMS ((cp_parser *));
+ (cp_parser *);
static tree cp_parser_base_specifier
- PARAMS ((cp_parser *));
+ (cp_parser *);

/* Special member functions [gram.special] */

static tree cp_parser_conversion_function_id
- PARAMS ((cp_parser *));
+ (cp_parser *);
static tree cp_parser_conversion_type_id
- PARAMS ((cp_parser *));
+ (cp_parser *);
static tree cp_parser_conversion_declarator_opt
- PARAMS ((cp_parser *));
+ (cp_parser *);
static bool cp_parser_ctor_initializer_opt
- PARAMS ((cp_parser *));
+ (cp_parser *);
static void cp_parser_mem_initializer_list
- PARAMS ((cp_parser *));
+ (cp_parser *);
static tree cp_parser_mem_initializer
- PARAMS ((cp_parser *));
+ (cp_parser *);
static tree cp_parser_mem_initializer_id
- PARAMS ((cp_parser *));
+ (cp_parser *);

/* Overloading [gram.over] */

static tree cp_parser_operator_function_id
- PARAMS ((cp_parser *));
+ (cp_parser *);
static tree cp_parser_operator
- PARAMS ((cp_parser *));
+ (cp_parser *);

/* Templates [gram.temp] */

static void cp_parser_template_declaration
- PARAMS ((cp_parser *, bool));
+ (cp_parser *, bool);
static tree cp_parser_template_parameter_list
- PARAMS ((cp_parser *));
+ (cp_parser *);
static tree cp_parser_template_parameter
- PARAMS ((cp_parser *));
+ (cp_parser *);
static tree cp_parser_type_parameter
- PARAMS ((cp_parser *));
+ (cp_parser *);
static tree cp_parser_template_id
- PARAMS ((cp_parser *, bool, bool));
+ (cp_parser *, bool, bool);
static tree cp_parser_template_name
- PARAMS ((cp_parser *, bool, bool));
+ (cp_parser *, bool, bool);
static tree cp_parser_template_argument_list
- PARAMS ((cp_parser *));
+ (cp_parser *);
static tree cp_parser_template_argument
- PARAMS ((cp_parser *));
+ (cp_parser *);
static void cp_parser_explicit_instantiation
- PARAMS ((cp_parser *));
+ (cp_parser *);
static void cp_parser_explicit_specialization
- PARAMS ((cp_parser *));
+ (cp_parser *);

/* Exception handling [gram.exception] */

static tree cp_parser_try_block
- PARAMS ((cp_parser *));
+ (cp_parser *);
static bool cp_parser_function_try_block
- PARAMS ((cp_parser *));
+ (cp_parser *);
static void cp_parser_handler_seq
- PARAMS ((cp_parser *));
+ (cp_parser *);
static void cp_parser_handler
- PARAMS ((cp_parser *));
+ (cp_parser *);
static tree cp_parser_exception_declaration
- PARAMS ((cp_parser *));
+ (cp_parser *);
static tree cp_parser_throw_expression
- PARAMS ((cp_parser *));
+ (cp_parser *);
static tree cp_parser_exception_specification_opt
- PARAMS ((cp_parser *));
+ (cp_parser *);
static tree cp_parser_type_id_list
- PARAMS ((cp_parser *));
+ (cp_parser *);

/* GNU Extensions */

static tree cp_parser_asm_specification_opt
- PARAMS ((cp_parser *));
+ (cp_parser *);
static tree cp_parser_asm_operand_list
- PARAMS ((cp_parser *));
+ (cp_parser *);
static tree cp_parser_asm_clobber_list
- PARAMS ((cp_parser *));
+ (cp_parser *);
static tree cp_parser_attributes_opt
- PARAMS ((cp_parser *));
+ (cp_parser *);
static tree cp_parser_attribute_list
- PARAMS ((cp_parser *));
+ (cp_parser *);
static bool cp_parser_extension_opt
- PARAMS ((cp_parser *, int *));
+ (cp_parser *, int *);
static void cp_parser_label_declaration
- PARAMS ((cp_parser *));
+ (cp_parser *);

/* Utility Routines */

static tree cp_parser_lookup_name
- PARAMS ((cp_parser *, tree, bool, bool, bool, bool));
+ (cp_parser *, tree, bool, bool, bool, bool);
static tree cp_parser_lookup_name_simple
- PARAMS ((cp_parser *, tree));
+ (cp_parser *, tree);
static tree cp_parser_resolve_typename_type
- PARAMS ((cp_parser *, tree));
+ (cp_parser *, tree);
static tree cp_parser_maybe_treat_template_as_class
(tree, bool);
static bool cp_parser_check_declarator_template_parameters
- PARAMS ((cp_parser *, tree));
+ (cp_parser *, tree);
static bool cp_parser_check_template_parameters
- PARAMS ((cp_parser *, unsigned));
+ (cp_parser *, unsigned);
static tree cp_parser_binary_expression
- PARAMS ((cp_parser *,
- const cp_parser_token_tree_map,
- cp_parser_expression_fn));
+ (cp_parser *, const cp_parser_token_tree_map, cp_parser_expression_fn);
static tree cp_parser_global_scope_opt
- PARAMS ((cp_parser *, bool));
+ (cp_parser *, bool);
static bool cp_parser_constructor_declarator_p
(cp_parser *, bool);
static tree cp_parser_function_definition_from_specifiers_and_declarator
- PARAMS ((cp_parser *, tree, tree, tree, tree));
+ (cp_parser *, tree, tree, tree, tree);
static tree cp_parser_function_definition_after_declarator
- PARAMS ((cp_parser *, bool));
+ (cp_parser *, bool);
static void cp_parser_template_declaration_after_export
- PARAMS ((cp_parser *, bool));
+ (cp_parser *, bool);
static tree cp_parser_single_declaration
- PARAMS ((cp_parser *, bool, bool *));
+ (cp_parser *, bool, bool *);
static tree cp_parser_functional_cast
- PARAMS ((cp_parser *, tree));
+ (cp_parser *, tree);
static void cp_parser_late_parsing_for_member
- PARAMS ((cp_parser *, tree));
+ (cp_parser *, tree);
static void cp_parser_late_parsing_default_args
(cp_parser *, tree);
static tree cp_parser_sizeof_operand
- PARAMS ((cp_parser *, enum rid));
+ (cp_parser *, enum rid);
static bool cp_parser_declares_only_class_p
- PARAMS ((cp_parser *));
+ (cp_parser *);
static bool cp_parser_friend_p
- PARAMS ((tree));
+ (tree);
static cp_token *cp_parser_require
- PARAMS ((cp_parser *, enum cpp_ttype, const char *));
+ (cp_parser *, enum cpp_ttype, const char *);
static cp_token *cp_parser_require_keyword
- PARAMS ((cp_parser *, enum rid, const char *));
+ (cp_parser *, enum rid, const char *);
static bool cp_parser_token_starts_function_definition_p
- PARAMS ((cp_token *));
+ (cp_token *);
static bool cp_parser_next_token_starts_class_definition_p
(cp_parser *);
static enum tag_types cp_parser_token_is_class_key
- PARAMS ((cp_token *));
+ (cp_token *);
static void cp_parser_check_class_key
(enum tag_types, tree type);
static bool cp_parser_optional_template_keyword
@@ -1749,43 +1719,43 @@
static void cp_parser_cache_group
(cp_parser *, cp_token_cache *, enum cpp_ttype, unsigned);
static void cp_parser_parse_tentatively
- PARAMS ((cp_parser *));
+ (cp_parser *);
static void cp_parser_commit_to_tentative_parse
- PARAMS ((cp_parser *));
+ (cp_parser *);
static void cp_parser_abort_tentative_parse
- PARAMS ((cp_parser *));
+ (cp_parser *);
static bool cp_parser_parse_definitely
- PARAMS ((cp_parser *));
+ (cp_parser *);
static inline bool cp_parser_parsing_tentatively
- PARAMS ((cp_parser *));
+ (cp_parser *);
static bool cp_parser_committed_to_tentative_parse
- PARAMS ((cp_parser *));
+ (cp_parser *);
static void cp_parser_error
- PARAMS ((cp_parser *, const char *));
+ (cp_parser *, const char *);
static bool cp_parser_simulate_error
- PARAMS ((cp_parser *));
+ (cp_parser *);
static void cp_parser_check_type_definition
- PARAMS ((cp_parser *));
+ (cp_parser *);
static bool cp_parser_skip_to_closing_parenthesis
- PARAMS ((cp_parser *));
+ (cp_parser *);
static bool cp_parser_skip_to_closing_parenthesis_or_comma
(cp_parser *);
static void cp_parser_skip_to_end_of_statement
- PARAMS ((cp_parser *));
+ (cp_parser *);
static void cp_parser_skip_to_end_of_block_or_statement
- PARAMS ((cp_parser *));
+ (cp_parser *);
static void cp_parser_skip_to_closing_brace
(cp_parser *);
static void cp_parser_skip_until_found
- PARAMS ((cp_parser *, enum cpp_ttype, const char *));
+ (cp_parser *, enum cpp_ttype, const char *);
static bool cp_parser_error_occurred
- PARAMS ((cp_parser *));
+ (cp_parser *);
static bool cp_parser_allow_gnu_extensions_p
- PARAMS ((cp_parser *));
+ (cp_parser *);
static bool cp_parser_is_string_literal
- PARAMS ((cp_token *));
+ (cp_token *);
static bool cp_parser_is_keyword
- PARAMS ((cp_token *, enum rid));
+ (cp_token *, enum rid);
static bool cp_parser_dependent_type_p
(tree);
static bool cp_parser_value_dependent_expression_p
@@ -1803,17 +1773,16 @@
static void cp_parser_start_deferring_access_checks
(cp_parser *);
static tree cp_parser_stop_deferring_access_checks
- PARAMS ((cp_parser *));
+ (cp_parser *);
static void cp_parser_perform_deferred_access_checks
- PARAMS ((tree));
+ (tree);
static tree cp_parser_scope_through_which_access_occurs
(tree, tree, tree);

/* Returns non-zero if we are parsing tentatively. */

static inline bool
-cp_parser_parsing_tentatively (parser)
- cp_parser *parser;
+cp_parser_parsing_tentatively (cp_parser* parser)
{
return parser->context->next != NULL;
}
@@ -1821,8 +1790,7 @@
/* Returns non-zero if TOKEN is a string literal. */

static bool
-cp_parser_is_string_literal (token)
- cp_token *token;
+cp_parser_is_string_literal (cp_token* token)
{
return (token->type == CPP_STRING || token->type == CPP_WSTRING);
}
@@ -1830,9 +1798,7 @@
/* Returns non-zero if TOKEN is the indicated KEYWORD. */

static bool
-cp_parser_is_keyword (token, keyword)
- cp_token *token;
- enum rid keyword;
+cp_parser_is_keyword (cp_token* token, enum rid keyword)
{
return token->keyword == keyword;
}
@@ -1841,8 +1807,7 @@
[temp.dep.type]. */

static bool
-cp_parser_dependent_type_p (type)
- tree type;
+cp_parser_dependent_type_p (tree type)
{
tree scope;

@@ -2025,8 +1990,7 @@
[temp.dep.expr]. */

static bool
-cp_parser_type_dependent_expression_p (expression)
- tree expression;
+cp_parser_type_dependent_expression_p (tree expression)
{
if (!processing_template_decl)
return false;
@@ -2157,8 +2121,7 @@
declaration named. */

static tree
-cp_parser_stop_deferring_access_checks (parser)
- cp_parser *parser;
+cp_parser_stop_deferring_access_checks (cp_parser* parser)
{
tree access_checks;

@@ -2173,8 +2136,7 @@
documented with cp_parser_stop_deferrring_access_checks. */

static void
-cp_parser_perform_deferred_access_checks (access_checks)
- tree access_checks;
+cp_parser_perform_deferred_access_checks (tree access_checks)
{
tree deferred_check;

@@ -2194,12 +2156,9 @@
NESTED_NAME_SPECIFIER is `A'. */

tree
-cp_parser_scope_through_which_access_occurs (decl,
- object_type,
- nested_name_specifier)
- tree decl;
- tree object_type;
- tree nested_name_specifier;
+cp_parser_scope_through_which_access_occurs (tree decl,
+ tree object_type,
+ tree nested_name_specifier)
{
tree scope;
tree qualifying_type = NULL_TREE;
@@ -2239,9 +2198,7 @@
/* Issue the indicated error MESSAGE. */

static void
-cp_parser_error (parser, message)
- cp_parser *parser;
- const char *message;
+cp_parser_error (cp_parser* parser, const char* message)
{
/* Output the MESSAGE -- unless we're parsing tentatively. */
if (!cp_parser_simulate_error (parser))
@@ -2253,8 +2210,7 @@
simulated; false if a messgae should be issued by the caller. */

static bool
-cp_parser_simulate_error (parser)
- cp_parser *parser;
+cp_parser_simulate_error (cp_parser* parser)
{
if (cp_parser_parsing_tentatively (parser)
&& !cp_parser_committed_to_tentative_parse (parser))
@@ -2270,8 +2226,7 @@
issued. */

static void
-cp_parser_check_type_definition (parser)
- cp_parser *parser;
+cp_parser_check_type_definition (cp_parser* parser)
{
/* If types are forbidden here, issue a message. */
if (parser->type_definition_forbidden_message)
@@ -2340,8 +2295,7 @@
non-nested `}' comes first, then we stop before consuming that. */

static void
-cp_parser_skip_to_end_of_statement (parser)
- cp_parser *parser;
+cp_parser_skip_to_end_of_statement (cp_parser* parser)
{
unsigned nesting_depth = 0;

@@ -2400,8 +2354,7 @@
have consumed a non-nested `;'. */

static void
-cp_parser_skip_to_end_of_block_or_statement (parser)
- cp_parser *parser;
+cp_parser_skip_to_end_of_block_or_statement (cp_parser* parser)
{
unsigned nesting_depth = 0;

@@ -2469,7 +2422,7 @@
/* Create a new C++ parser. */

static cp_parser *
-cp_parser_new ()
+cp_parser_new (void)
{
cp_parser *parser;

@@ -2516,8 +2469,7 @@
identifier. */

static tree
-cp_parser_identifier (parser)
- cp_parser *parser;
+cp_parser_identifier (cp_parser* parser)
{
cp_token *token;

@@ -2537,8 +2489,7 @@
Returns TRUE if all went well. */

static bool
-cp_parser_translation_unit (parser)
- cp_parser *parser;
+cp_parser_translation_unit (cp_parser* parser)
{
while (true)
{
@@ -3211,11 +3162,9 @@
names are looked up in uninstantiated templates. */

static tree
-cp_parser_unqualified_id (parser, template_keyword_p,
- check_dependency_p)
- cp_parser *parser;
- bool template_keyword_p;
- bool check_dependency_p;
+cp_parser_unqualified_id (cp_parser* parser,
+ bool template_keyword_p,
+ bool check_dependency_p)
{
cp_token *token;

@@ -4394,8 +4343,7 @@
is returned even if there is only a single expression in the list. */

static tree
-cp_parser_expression_list (parser)
- cp_parser *parser;
+cp_parser_expression_list (cp_parser* parser)
{
tree expression_list = NULL_TREE;

@@ -4444,10 +4392,9 @@
or ERROR_MARK_NODE if no type-name is present. */

static void
-cp_parser_pseudo_destructor_name (parser, scope, type)
- cp_parser *parser;
- tree *scope;
- tree *type;
+cp_parser_pseudo_destructor_name (cp_parser* parser,
+ tree* scope,
+ tree* type)
{
bool nested_name_specifier_p;

@@ -4692,8 +4639,7 @@
unary-operator, the corresponding tree code is returned. */

static enum tree_code
-cp_parser_unary_operator (token)
- cp_token *token;
+cp_parser_unary_operator (cp_token* token)
{
switch (token->type)
{
@@ -4728,8 +4674,7 @@
Returns a representation of the expression. */

static tree
-cp_parser_new_expression (parser)
- cp_parser *parser;
+cp_parser_new_expression (cp_parser* parser)
{
bool global_scope_p;
tree placement;
@@ -4785,8 +4730,7 @@
Returns the same representation as for an expression-list. */

static tree
-cp_parser_new_placement (parser)
- cp_parser *parser;
+cp_parser_new_placement (cp_parser* parser)
{
tree expression_list;

@@ -4810,8 +4754,7 @@
and whose TREE_VALUE is the new-declarator. */

static tree
-cp_parser_new_type_id (parser)
- cp_parser *parser;
+cp_parser_new_type_id (cp_parser* parser)
{
tree type_specifier_seq;
tree declarator;
@@ -4844,8 +4787,7 @@
cp_parser_declarator for the representations used. */

static tree
-cp_parser_new_declarator_opt (parser)
- cp_parser *parser;
+cp_parser_new_declarator_opt (cp_parser* parser)
{
enum tree_code code;
tree type;
@@ -4895,8 +4837,7 @@
documented for cp_parser_direct_declarator. */

static tree
-cp_parser_direct_new_declarator (parser)
- cp_parser *parser;
+cp_parser_direct_new_declarator (cp_parser* parser)
{
tree declarator = NULL_TREE;

@@ -4956,8 +4897,7 @@
expression-list, VOID_ZERO_NODE is returned. */

static tree
-cp_parser_new_initializer (parser)
- cp_parser *parser;
+cp_parser_new_initializer (cp_parser* parser)
{
tree expression_list;

@@ -4984,8 +4924,7 @@
Returns a representation of the expression. */

static tree
-cp_parser_delete_expression (parser)
- cp_parser *parser;
+cp_parser_delete_expression (cp_parser* parser)
{
bool global_scope_p;
bool array_p;
@@ -5121,8 +5060,7 @@
Returns a representation of the expression. */

static tree
-cp_parser_pm_expression (parser)
- cp_parser *parser;
+cp_parser_pm_expression (cp_parser* parser)
{
tree cast_expr;
tree pm_expr;
@@ -5173,8 +5111,7 @@
Returns a representation of the expression. */

static tree
-cp_parser_multiplicative_expression (parser)
- cp_parser *parser;
+cp_parser_multiplicative_expression (cp_parser* parser)
{
static const cp_parser_token_tree_map map = {
{ CPP_MULT, MULT_EXPR },
@@ -5198,8 +5135,7 @@
Returns a representation of the expression. */

static tree
-cp_parser_additive_expression (parser)
- cp_parser *parser;
+cp_parser_additive_expression (cp_parser* parser)
{
static const cp_parser_token_tree_map map = {
{ CPP_PLUS, PLUS_EXPR },
@@ -5222,8 +5158,7 @@
Returns a representation of the expression. */

static tree
-cp_parser_shift_expression (parser)
- cp_parser *parser;
+cp_parser_shift_expression (cp_parser* parser)
{
static const cp_parser_token_tree_map map = {
{ CPP_LSHIFT, LSHIFT_EXPR },
@@ -5254,8 +5189,7 @@
Returns a representation of the expression. */

static tree
-cp_parser_relational_expression (parser)
- cp_parser *parser;
+cp_parser_relational_expression (cp_parser* parser)
{
static const cp_parser_token_tree_map map = {
{ CPP_LESS, LT_EXPR },
@@ -5282,8 +5216,7 @@
Returns a representation of the expression. */

static tree
-cp_parser_equality_expression (parser)
- cp_parser *parser;
+cp_parser_equality_expression (cp_parser* parser)
{
static const cp_parser_token_tree_map map = {
{ CPP_EQ_EQ, EQ_EXPR },
@@ -5305,8 +5238,7 @@
Returns a representation of the expression. */

static tree
-cp_parser_and_expression (parser)
- cp_parser *parser;
+cp_parser_and_expression (cp_parser* parser)
{
static const cp_parser_token_tree_map map = {
{ CPP_AND, BIT_AND_EXPR },
@@ -5327,8 +5259,7 @@
Returns a representation of the expression. */

static tree
-cp_parser_exclusive_or_expression (parser)
- cp_parser *parser;
+cp_parser_exclusive_or_expression (cp_parser* parser)
{
static const cp_parser_token_tree_map map = {
{ CPP_XOR, BIT_XOR_EXPR },
@@ -5350,8 +5281,7 @@
Returns a representation of the expression. */

static tree
-cp_parser_inclusive_or_expression (parser)
- cp_parser *parser;
+cp_parser_inclusive_or_expression (cp_parser* parser)
{
static const cp_parser_token_tree_map map = {
{ CPP_OR, BIT_IOR_EXPR },
@@ -5372,8 +5302,7 @@
Returns a representation of the expression. */

static tree
-cp_parser_logical_and_expression (parser)
- cp_parser *parser;
+cp_parser_logical_and_expression (cp_parser* parser)
{
static const cp_parser_token_tree_map map = {
{ CPP_AND_AND, TRUTH_ANDIF_EXPR },
@@ -5394,8 +5323,7 @@
Returns a representation of the expression. */

static tree
-cp_parser_logical_or_expression (parser)
- cp_parser *parser;
+cp_parser_logical_or_expression (cp_parser* parser)
{
static const cp_parser_token_tree_map map = {
{ CPP_OR_OR, TRUTH_ORIF_EXPR },
@@ -5421,8 +5349,7 @@
Returns a representation of the expression. */

static tree
-cp_parser_conditional_expression (parser)
- cp_parser *parser;
+cp_parser_conditional_expression (cp_parser* parser)
{
tree logical_or_expr;

@@ -5453,9 +5380,7 @@
? : assignment-expression */

static tree
-cp_parser_question_colon_clause (parser, logical_or_expr)
- cp_parser *parser;
- tree logical_or_expr;
+cp_parser_question_colon_clause (cp_parser* parser, tree logical_or_expr)
{
tree expr;
tree assignment_expr;
@@ -5491,8 +5416,7 @@
Returns a representation for the expression. */

static tree
-cp_parser_assignment_expression (parser)
- cp_parser *parser;
+cp_parser_assignment_expression (cp_parser* parser)
{
tree expr;

@@ -5553,8 +5477,7 @@
operator, ERROR_MARK is returned. */

static enum tree_code
-cp_parser_assignment_operator_opt (parser)
- cp_parser *parser;
+cp_parser_assignment_operator_opt (cp_parser* parser)
{
enum tree_code op;
cp_token *token;
@@ -5637,8 +5560,7 @@
Returns a representation of the expression. */

static tree
-cp_parser_expression (parser)
- cp_parser *parser;
+cp_parser_expression (cp_parser* parser)
{
tree expression = NULL_TREE;
bool saw_comma_p = false;
@@ -5695,8 +5617,7 @@
conditional-expression */

static tree
-cp_parser_constant_expression (parser)
- cp_parser *parser;
+cp_parser_constant_expression (cp_parser* parser)
{
bool saved_constant_expression_p;
tree expression;
@@ -5745,8 +5666,7 @@
try-block */

static void
-cp_parser_statement (parser)
- cp_parser *parser;
+cp_parser_statement (cp_parser* parser)
{
tree statement;
cp_token *token;
@@ -5846,8 +5766,7 @@
an ordinary label, returns a LABEL_STMT. */

static tree
-cp_parser_labeled_statement (parser)
- cp_parser *parser;
+cp_parser_labeled_statement (cp_parser* parser)
{
cp_token *token;
tree statement = NULL_TREE;
@@ -5907,8 +5826,7 @@
statement consists of nothing more than an `;'. */

static tree
-cp_parser_expression_statement (parser)
- cp_parser *parser;
+cp_parser_expression_statement (cp_parser* parser)
{
tree statement;

@@ -5969,8 +5887,7 @@
statement-seq [opt] statement */

static void
-cp_parser_statement_seq_opt (parser)
- cp_parser *parser;
+cp_parser_statement_seq_opt (cp_parser* parser)
{
/* Scan statements until there aren't any more. */
while (true)
@@ -5995,8 +5912,7 @@
Returns the new IF_STMT or SWITCH_STMT. */

static tree
-cp_parser_selection_statement (parser)
- cp_parser *parser;
+cp_parser_selection_statement (cp_parser* parser)
{
cp_token *token;
enum rid keyword;
@@ -6100,8 +6016,7 @@
Returns the expression that should be tested. */

static tree
-cp_parser_condition (parser)
- cp_parser *parser;
+cp_parser_condition (cp_parser* parser)
{
tree type_specifiers;
const char *saved_message;
@@ -6181,8 +6096,7 @@
Returns the new WHILE_STMT, DO_STMT, or FOR_STMT. */

static tree
-cp_parser_iteration_statement (parser)
- cp_parser *parser;
+cp_parser_iteration_statement (cp_parser* parser)
{
cp_token *token;
enum rid keyword;
@@ -6292,8 +6206,7 @@
simple-declaration */

static void
-cp_parser_for_init_statement (parser)
- cp_parser *parser;
+cp_parser_for_init_statement (cp_parser* parser)
{
/* If the next token is a `;', then we have an empty
expression-statement. Gramatically, this is also a
@@ -6335,8 +6248,7 @@
GOTO_STMT. */

static tree
-cp_parser_jump_statement (parser)
- cp_parser *parser;
+cp_parser_jump_statement (cp_parser* parser)
{
tree statement = error_mark_node;
cp_token *token;
@@ -6410,8 +6322,7 @@
block-declaration */

static void
-cp_parser_declaration_statement (parser)
- cp_parser *parser;
+cp_parser_declaration_statement (cp_parser* parser)
{
/* Parse the block-declaration. */
cp_parser_block_declaration (parser, /*statement_p=*/true);
@@ -6432,8 +6343,7 @@
Returns the new statement. */

static tree
-cp_parser_implicitly_scoped_statement (parser)
- cp_parser *parser;
+cp_parser_implicitly_scoped_statement (cp_parser* parser)
{
tree statement;

@@ -6461,8 +6371,7 @@
scope. */

static void
-cp_parser_already_scoped_statement (parser)
- cp_parser *parser;
+cp_parser_already_scoped_statement (cp_parser* parser)
{
/* If the token is not a `{', then we must take special action. */
if (cp_lexer_next_token_is_not(parser->lexer, CPP_OPEN_BRACE))
@@ -6490,8 +6399,7 @@
declaration-seq declaration */

static void
-cp_parser_declaration_seq_opt (parser)
- cp_parser *parser;
+cp_parser_declaration_seq_opt (cp_parser* parser)
{
while (true)
{
@@ -6548,8 +6456,7 @@
__extension__ declaration */

static void
-cp_parser_declaration (parser)
- cp_parser *parser;
+cp_parser_declaration (cp_parser* parser)
{
cp_token token1;
cp_token token2;
@@ -6715,9 +6622,8 @@
function-definition as a simple-declaration. */

static void
-cp_parser_simple_declaration (parser, function_definition_allowed_p)
- cp_parser *parser;
- bool function_definition_allowed_p;
+cp_parser_simple_declaration (cp_parser* parser,
+ bool function_definition_allowed_p)
{
tree decl_specifiers;
tree attributes;
@@ -6871,12 +6777,10 @@
friendship is granted might not be a class. */

static tree
-cp_parser_decl_specifier_seq (parser, flags, attributes,
- declares_class_or_enum)
- cp_parser *parser;
- cp_parser_flags flags;
- tree *attributes;
- bool *declares_class_or_enum;
+cp_parser_decl_specifier_seq (cp_parser* parser,
+ cp_parser_flags flags,
+ tree* attributes,
+ bool* declares_class_or_enum)
{
tree decl_specs = NULL_TREE;
bool friend_p = false;
@@ -7069,8 +6973,7 @@
Returns an IDENTIFIER_NODE corresponding to the keyword used. */

static tree
-cp_parser_storage_class_specifier_opt (parser)
- cp_parser *parser;
+cp_parser_storage_class_specifier_opt (cp_parser* parser)
{
switch (cp_lexer_peek_token (parser->lexer)->keyword)
{
@@ -7098,8 +7001,7 @@
Returns an IDENTIFIER_NODE corresponding to the keyword used. */

static tree
-cp_parser_function_specifier_opt (parser)
- cp_parser *parser;
+cp_parser_function_specifier_opt (cp_parser* parser)
{
switch (cp_lexer_peek_token (parser->lexer)->keyword)
{
@@ -7121,8 +7023,7 @@
extern string-literal declaration */

static void
-cp_parser_linkage_specification (parser)
- cp_parser *parser;
+cp_parser_linkage_specification (cp_parser* parser)
{
cp_token *token;
tree linkage;
@@ -7199,8 +7100,7 @@
Returns an IDENTIFIER_NODE representing the operator. */

static tree
-cp_parser_conversion_function_id (parser)
- cp_parser *parser;
+cp_parser_conversion_function_id (cp_parser* parser)
{
tree type;
tree saved_scope;
@@ -7254,8 +7154,7 @@
Returns the TYPE specified. */

static tree
-cp_parser_conversion_type_id (parser)
- cp_parser *parser;
+cp_parser_conversion_type_id (cp_parser* parser)
{
tree attributes;
tree type_specifiers;
@@ -7284,8 +7183,7 @@
cp_parser_declarator for details. */

static tree
-cp_parser_conversion_declarator_opt (parser)
- cp_parser *parser;
+cp_parser_conversion_declarator_opt (cp_parser* parser)
{
enum tree_code code;
tree class_type;
@@ -7330,8 +7228,7 @@
Returns TRUE iff the ctor-initializer was actually present. */

static bool
-cp_parser_ctor_initializer_opt (parser)
- cp_parser *parser;
+cp_parser_ctor_initializer_opt (cp_parser* parser)
{
/* If the next token is not a `:', then there is no
ctor-initializer. */
@@ -7359,8 +7256,7 @@
mem-initializer , mem-initializer-list */

static void
-cp_parser_mem_initializer_list (parser)
- cp_parser *parser;
+cp_parser_mem_initializer_list (cp_parser* parser)
{
tree mem_initializer_list = NULL_TREE;

@@ -7407,8 +7303,7 @@
the TREE_VALUE is the expression-list. */

static tree
-cp_parser_mem_initializer (parser)
- cp_parser *parser;
+cp_parser_mem_initializer (cp_parser* parser)
{
tree mem_initializer_id;
tree expression_list;
@@ -7447,8 +7342,7 @@
to be initialized for the second production. */

static tree
-cp_parser_mem_initializer_id (parser)
- cp_parser *parser;
+cp_parser_mem_initializer_id (cp_parser* parser)
{
bool global_scope_p;
bool nested_name_specifier_p;
@@ -7515,8 +7409,7 @@
human-readable spelling of the identifier, e.g., `operator +'. */

static tree
-cp_parser_operator_function_id (parser)
- cp_parser *parser;
+cp_parser_operator_function_id (cp_parser* parser)
{
/* Look for the `operator' keyword. */
if (!cp_parser_require_keyword (parser, RID_OPERATOR, "`operator'"))
@@ -7541,8 +7434,7 @@
human-readable spelling of the identifier, e.g., `operator +'. */

static tree
-cp_parser_operator (parser)
- cp_parser *parser;
+cp_parser_operator (cp_parser* parser)
{
tree id = NULL_TREE;
cp_token *token;
@@ -7803,9 +7695,7 @@
template < template-parameter-list > */

static void
-cp_parser_template_declaration (parser, member_p)
- cp_parser *parser;
- bool member_p;
+cp_parser_template_declaration (cp_parser* parser, bool member_p)
{
/* Check for `export'. */
if (cp_lexer_next_token_is_keyword (parser->lexer, RID_EXPORT))
@@ -7829,8 +7719,7 @@
The nodes are connected via their TREE_CHAINs. */

static tree
-cp_parser_template_parameter_list (parser)
- cp_parser *parser;
+cp_parser_template_parameter_list (cp_parser* parser)
{
tree parameter_list = NULL_TREE;

@@ -7867,8 +7756,7 @@
TREE_PURPOSE is the default value, if any. */

static tree
-cp_parser_template_parameter (parser)
- cp_parser *parser;
+cp_parser_template_parameter (cp_parser* parser)
{
cp_token *token;

@@ -7933,8 +7821,7 @@
the declaration of the parameter. */

static tree
-cp_parser_type_parameter (parser)
- cp_parser *parser;
+cp_parser_type_parameter (cp_parser* parser)
{
cp_token *token;
tree parameter;
@@ -8241,10 +8128,9 @@
names are looked up inside uninstantiated templates. */

static tree
-cp_parser_template_name (parser, template_keyword_p, check_dependency_p)
- cp_parser *parser;
- bool template_keyword_p;
- bool check_dependency_p;
+cp_parser_template_name (cp_parser* parser,
+ bool template_keyword_p,
+ bool check_dependency_p)
{
tree identifier;
tree decl;
@@ -8344,8 +8230,7 @@
argument. */

static tree
-cp_parser_template_argument_list (parser)
- cp_parser *parser;
+cp_parser_template_argument_list (cp_parser* parser)
{
tree arguments = NULL_TREE;

@@ -8381,8 +8266,7 @@
OVERLOAD. */

static tree
-cp_parser_template_argument (parser)
- cp_parser *parser;
+cp_parser_template_argument (cp_parser* parser)
{
tree argument;
bool template_p;
@@ -8459,8 +8343,7 @@
decl-specifier-seq [opt] declarator [opt] ; */

static void
-cp_parser_explicit_instantiation (parser)
- cp_parser *parser;
+cp_parser_explicit_instantiation (cp_parser* parser)
{
bool declares_class_or_enum;
tree decl_specifiers;
@@ -8539,8 +8422,7 @@
template <> template-declaration */

static void
-cp_parser_explicit_specialization (parser)
- cp_parser *parser;
+cp_parser_explicit_specialization (cp_parser* parser)
{
/* Look for the `template' keyword. */
cp_parser_require_keyword (parser, RID_TEMPLATE, "`template'");
@@ -8610,18 +8492,12 @@
is set to FALSE. */

static tree
-cp_parser_type_specifier (parser,
- flags,
- is_friend,
- is_declaration,
- declares_class_or_enum,
- is_cv_qualifier)
- cp_parser *parser;
- cp_parser_flags flags;
- bool is_friend;
- bool is_declaration;
- bool *declares_class_or_enum;
- bool *is_cv_qualifier;
+cp_parser_type_specifier (cp_parser* parser,
+ cp_parser_flags flags,
+ bool is_friend,
+ bool is_declaration,
+ bool* declares_class_or_enum,
+ bool* is_cv_qualifier)
{
tree type_spec = NULL_TREE;
cp_token *token;
@@ -8741,9 +8617,7 @@
productions, the value returned is the indicated TYPE_DECL. */

static tree
-cp_parser_simple_type_specifier (parser, flags)
- cp_parser *parser;
- cp_parser_flags flags;
+cp_parser_simple_type_specifier (cp_parser* parser, cp_parser_flags flags)
{
tree type = NULL_TREE;
cp_token *token;
@@ -8860,8 +8734,7 @@
Returns a TYPE_DECL for the the type. */

static tree
-cp_parser_type_name (parser)
- cp_parser *parser;
+cp_parser_type_name (cp_parser* parser)
{
tree type_decl;
tree identifier;
@@ -8924,10 +8797,9 @@
Returns the TYPE specified. */

static tree
-cp_parser_elaborated_type_specifier (parser, is_friend, is_declaration)
- cp_parser *parser;
- bool is_friend;
- bool is_declaration;
+cp_parser_elaborated_type_specifier (cp_parser* parser,
+ bool is_friend,
+ bool is_declaration)
{
enum tag_types tag_type;
tree identifier;
@@ -9117,8 +8989,7 @@
Returns an ENUM_TYPE representing the enumeration. */

static tree
-cp_parser_enum_specifier (parser)
- cp_parser *parser;
+cp_parser_enum_specifier (cp_parser* parser)
{
cp_token *token;
tree identifier = NULL_TREE;
@@ -9170,9 +9041,7 @@
enumerator-list , enumerator-definition */

static void
-cp_parser_enumerator_list (parser, type)
- cp_parser *parser;
- tree type;
+cp_parser_enumerator_list (cp_parser* parser, tree type)
{
while (true)
{
@@ -9209,9 +9078,7 @@
identifier */

static void
-cp_parser_enumerator_definition (parser, type)
- cp_parser *parser;
- tree type;
+cp_parser_enumerator_definition (cp_parser* parser, tree type)
{
cp_token *token;
tree identifier;
@@ -9248,8 +9115,7 @@
Returns the NAMESPACE_DECL for the namespace. */

static tree
-cp_parser_namespace_name (parser)
- cp_parser *parser;
+cp_parser_namespace_name (cp_parser* parser)
{
tree identifier;
tree namespace_decl;
@@ -9313,8 +9179,7 @@
namespace { namespace-body } */

static void
-cp_parser_namespace_definition (parser)
- cp_parser *parser;
+cp_parser_namespace_definition (cp_parser* parser)
{
tree identifier;

@@ -9348,8 +9213,7 @@
declaration-seq [opt] */

static void
-cp_parser_namespace_body (parser)
- cp_parser *parser;
+cp_parser_namespace_body (cp_parser* parser)
{
cp_parser_declaration_seq_opt (parser);
}
@@ -9360,8 +9224,7 @@
namespace identifier = qualified-namespace-specifier ; */

static void
-cp_parser_namespace_alias_definition (parser)
- cp_parser *parser;
+cp_parser_namespace_alias_definition (cp_parser* parser)
{
tree identifier;
tree namespace_specifier;
@@ -9393,8 +9256,7 @@
namespace. */

static tree
-cp_parser_qualified_namespace_specifier (parser)
- cp_parser *parser;
+cp_parser_qualified_namespace_specifier (cp_parser* parser)
{
/* Look for the optional `::'. */
cp_parser_global_scope_opt (parser,
@@ -9416,8 +9278,7 @@
using :: unqualified-id ; */

static void
-cp_parser_using_declaration (parser)
- cp_parser *parser;
+cp_parser_using_declaration (cp_parser* parser)
{
cp_token *token;
bool typename_p = false;
@@ -9497,8 +9358,7 @@
namespace-name ; */

static void
-cp_parser_using_directive (parser)
- cp_parser *parser;
+cp_parser_using_directive (cp_parser* parser)
{
tree namespace_decl;

@@ -9538,8 +9398,7 @@
: asm-operand-list [opt] ) ; */

static void
-cp_parser_asm_definition (parser)
- cp_parser *parser;
+cp_parser_asm_definition (cp_parser* parser)
{
cp_token *token;
tree string;
@@ -9689,20 +9548,13 @@
is FALSE. */

static tree
-cp_parser_init_declarator (parser,
- decl_specifiers,
- prefix_attributes,
- access_checks,
- function_definition_allowed_p,
- member_p,
- function_definition_p)
- cp_parser *parser;
- tree decl_specifiers;
- tree prefix_attributes;
- tree access_checks;
- bool function_definition_allowed_p;
- bool member_p;
- bool *function_definition_p;
+cp_parser_init_declarator (cp_parser* parser,
+ tree decl_specifiers,
+ tree prefix_attributes,
+ tree access_checks,
+ bool function_definition_allowed_p,
+ bool member_p,
+ bool* function_definition_p)
{
cp_token *token;
tree declarator;
@@ -10027,10 +9879,9 @@
expression, not a declaration.) */

static tree
-cp_parser_declarator (parser, dcl_kind, ctor_dtor_or_conv_p)
- cp_parser *parser;
- cp_parser_declarator_kind dcl_kind;
- bool *ctor_dtor_or_conv_p;
+cp_parser_declarator (cp_parser* parser,
+ cp_parser_declarator_kind dcl_kind,
+ bool* ctor_dtor_or_conv_p)
{
cp_token *token;
tree declarator;
@@ -10134,10 +9985,9 @@
indicating the size of the array is the second operand. */

static tree
-cp_parser_direct_declarator (parser, dcl_kind, ctor_dtor_or_conv_p)
- cp_parser *parser;
- cp_parser_declarator_kind dcl_kind;
- bool *ctor_dtor_or_conv_p;
+cp_parser_direct_declarator (cp_parser* parser,
+ cp_parser_declarator_kind dcl_kind,
+ bool* ctor_dtor_or_conv_p)
{
cp_token *token;
tree declarator = NULL_TREE;
@@ -10429,10 +10279,9 @@
cv-qualifiers. Returns ERROR_MARK if an error occurred. */

static enum tree_code
-cp_parser_ptr_operator (parser, type, cv_qualifier_seq)
- cp_parser *parser;
- tree *type;
- tree *cv_qualifier_seq;
+cp_parser_ptr_operator (cp_parser* parser,
+ tree* type,
+ tree* cv_qualifier_seq)
{
enum tree_code code = ERROR_MARK;
cp_token *token;
@@ -10507,8 +10356,7 @@
representation of a cv-qualifier. */

static tree
-cp_parser_cv_qualifier_seq_opt (parser)
- cp_parser *parser;
+cp_parser_cv_qualifier_seq_opt (cp_parser* parser)
{
tree cv_qualifiers = NULL_TREE;

@@ -10543,8 +10391,7 @@
__restrict__ */

static tree
-cp_parser_cv_qualifier_opt (parser)
- cp_parser *parser;
+cp_parser_cv_qualifier_opt (cp_parser* parser)
{
cp_token *token;
tree cv_qualifier = NULL_TREE;
@@ -10584,8 +10431,7 @@
unqualified-id. */

static tree
-cp_parser_declarator_id (parser)
- cp_parser *parser;
+cp_parser_declarator_id (cp_parser* parser)
{
tree id_expression;

@@ -10623,8 +10469,7 @@
Returns the TYPE specified. */

static tree
-cp_parser_type_id (parser)
- cp_parser *parser;
+cp_parser_type_id (cp_parser* parser)
{
tree type_specifier_seq;
tree abstract_declarator;
@@ -10662,8 +10507,7 @@
type-specifier, or the TREE_PURPOSE is a list of attributes. */

static tree
-cp_parser_type_specifier_seq (parser)
- cp_parser *parser;
+cp_parser_type_specifier_seq (cp_parser* parser)
{
bool seen_type_specifier = false;
tree type_specifier_seq = NULL_TREE;
@@ -10725,8 +10569,7 @@
parameter-declaration-clause consisting only of an ellipsis. */

static tree
-cp_parser_parameter_declaration_clause (parser)
- cp_parser *parser;
+cp_parser_parameter_declaration_clause (cp_parser* parser)
{
tree parameters;
cp_token *token;
@@ -10809,8 +10652,7 @@
`void_list_node' is never appended to the list. */

static tree
-cp_parser_parameter_declaration_list (parser)
- cp_parser *parser;
+cp_parser_parameter_declaration_list (cp_parser* parser)
{
tree parameters = NULL_TREE;

@@ -11109,9 +10951,7 @@
be a `friend'. */

static tree
-cp_parser_function_definition (parser, friend_p)
- cp_parser *parser;
- bool *friend_p;
+cp_parser_function_definition (cp_parser* parser, bool* friend_p)
{
tree decl_specifiers;
tree attributes;
@@ -11305,9 +11145,7 @@
set to FALSE if there is no initializer present. */

static tree
-cp_parser_initializer (parser, is_parenthesized_init)
- cp_parser *parser;
- bool *is_parenthesized_init;
+cp_parser_initializer (cp_parser* parser, bool* is_parenthesized_init)
{
cp_token *token;
tree init;
@@ -11365,8 +11203,7 @@
trailing `,' was provided. */

static tree
-cp_parser_initializer_clause (parser)
- cp_parser *parser;
+cp_parser_initializer_clause (cp_parser* parser)
{
tree initializer;

@@ -11419,8 +11256,7 @@
IDENTIFIER_NODE naming the field to initialize. */

static tree
-cp_parser_initializer_list (parser)
- cp_parser *parser;
+cp_parser_initializer_list (cp_parser* parser)
{
tree initializers = NULL_TREE;

@@ -11612,8 +11448,7 @@
Returns the TREE_TYPE representing the class. */

static tree
-cp_parser_class_specifier (parser)
- cp_parser *parser;
+cp_parser_class_specifier (cp_parser* parser)
{
cp_token *token;
tree type;
@@ -11787,14 +11622,10 @@
body of the class. */

static tree
-cp_parser_class_head (parser,
- nested_name_specifier_p,
- deferring_access_checks_p,
- saved_access_checks)
- cp_parser *parser;
- bool *nested_name_specifier_p;
- bool *deferring_access_checks_p;
- tree *saved_access_checks;
+cp_parser_class_head (cp_parser* parser,
+ bool* nested_name_specifier_p,
+ bool* deferring_access_checks_p,
+ tree* saved_access_checks)
{
cp_token *token;
tree nested_name_specifier;
@@ -12056,8 +11887,7 @@
error. */

static enum tag_types
-cp_parser_class_key (parser)
- cp_parser *parser;
+cp_parser_class_key (cp_parser* parser)
{
cp_token *token;
enum tag_types tag_type;
@@ -12081,8 +11911,7 @@
access-specifier : member-specification [opt] */

static void
-cp_parser_member_specification_opt (parser)
- cp_parser *parser;
+cp_parser_member_specification_opt (cp_parser* parser)
{
while (true)
{
@@ -12148,8 +11977,7 @@
identifier [opt] attributes [opt] : constant-expression */

static void
-cp_parser_member_declaration (parser)
- cp_parser *parser;
+cp_parser_member_declaration (cp_parser* parser)
{
tree decl_specifiers;
tree prefix_attributes;
@@ -12495,8 +12323,7 @@
Otherwiser, ERROR_MARK_NODE is returned. */

static tree
-cp_parser_pure_specifier (parser)
- cp_parser *parser;
+cp_parser_pure_specifier (cp_parser* parser)
{
cp_token *token;

@@ -12522,8 +12349,7 @@
Returns a representation of the constant-expression. */

static tree
-cp_parser_constant_initializer (parser)
- cp_parser *parser;
+cp_parser_constant_initializer (cp_parser* parser)
{
/* Look for the `=' token. */
if (!cp_parser_require (parser, CPP_EQ, "`='"))
@@ -12570,8 +12396,7 @@
NULL_TREE, not ERROR_MARK_NODE. */

static tree
-cp_parser_base_clause (parser)
- cp_parser *parser;
+cp_parser_base_clause (cp_parser* parser)
{
tree bases = NULL_TREE;

@@ -12626,8 +12451,7 @@
(or the ERROR_MARK_NODE) indicating the type that was specified. */

static tree
-cp_parser_base_specifier (parser)
- cp_parser *parser;
+cp_parser_base_specifier (cp_parser* parser)
{
cp_token *token;
bool done = false;
@@ -12776,8 +12600,7 @@
TREE_VALUE of each node is a type. */

static tree
-cp_parser_exception_specification_opt (parser)
- cp_parser *parser;
+cp_parser_exception_specification_opt (cp_parser* parser)
{
cp_token *token;
tree type_id_list;
@@ -12829,8 +12652,7 @@
in the order that the types were presented. */

static tree
-cp_parser_type_id_list (parser)
- cp_parser *parser;
+cp_parser_type_id_list (cp_parser* parser)
{
tree types = NULL_TREE;

@@ -12861,8 +12683,7 @@
try compound-statement handler-seq */

static tree
-cp_parser_try_block (parser)
- cp_parser *parser;
+cp_parser_try_block (cp_parser* parser)
{
tree try_block;

@@ -12882,8 +12703,7 @@
try ctor-initializer [opt] function-body handler-seq */

static bool
-cp_parser_function_try_block (parser)
- cp_parser *parser;
+cp_parser_function_try_block (cp_parser* parser)
{
tree try_block;
bool ctor_initializer_p;
@@ -12912,8 +12732,7 @@
handler handler-seq [opt] */

static void
-cp_parser_handler_seq (parser)
- cp_parser *parser;
+cp_parser_handler_seq (cp_parser* parser)
{
while (true)
{
@@ -12935,8 +12754,7 @@
catch ( exception-declaration ) compound-statement */

static void
-cp_parser_handler (parser)
- cp_parser *parser;
+cp_parser_handler (cp_parser* parser)
{
tree handler;
tree declaration;
@@ -12963,8 +12781,7 @@
ellipsis variant is used. */

static tree
-cp_parser_exception_declaration (parser)
- cp_parser *parser;
+cp_parser_exception_declaration (cp_parser* parser)
{
tree type_specifiers;
tree declarator;
@@ -13006,8 +12823,7 @@
Returns a THROW_EXPR representing the throw-expression. */

static tree
-cp_parser_throw_expression (parser)
- cp_parser *parser;
+cp_parser_throw_expression (cp_parser* parser)
{
tree expression;

@@ -13035,8 +12851,7 @@
NULL_TREE. */

static tree
-cp_parser_asm_specification_opt (parser)
- cp_parser *parser;
+cp_parser_asm_specification_opt (cp_parser* parser)
{
cp_token *token;
tree asm_specification;
@@ -13083,8 +12898,7 @@
is a STRING_CST for the string literal before the parenthesis. */

static tree
-cp_parser_asm_operand_list (parser)
- cp_parser *parser;
+cp_parser_asm_operand_list (cp_parser* parser)
{
tree asm_operands = NULL_TREE;

@@ -13143,8 +12957,7 @@
appeared. The TREE_VALUE of each node is a STRING_CST. */

static tree
-cp_parser_asm_clobber_list (parser)
- cp_parser *parser;
+cp_parser_asm_clobber_list (cp_parser* parser)
{
tree clobbers = NULL_TREE;

@@ -13180,8 +12993,7 @@
The return value is as for cp_parser_attribute_list. */

static tree
-cp_parser_attributes_opt (parser)
- cp_parser *parser;
+cp_parser_attributes_opt (cp_parser* parser)
{
tree attributes = NULL_TREE;

@@ -13241,8 +13053,7 @@
any. */

static tree
-cp_parser_attribute_list (parser)
- cp_parser *parser;
+cp_parser_attribute_list (cp_parser* parser)
{
tree attribute_list = NULL_TREE;

@@ -13339,9 +13150,7 @@
for restoring the value of the PEDANTIC flag. */

static bool
-cp_parser_extension_opt (parser, saved_pedantic)
- cp_parser *parser;
- int *saved_pedantic;
+cp_parser_extension_opt (cp_parser* parser, int* saved_pedantic)
{
/* Save the old value of the PEDANTIC flag. */
*saved_pedantic = pedantic;
@@ -13370,8 +13179,7 @@
identifier */

static void
-cp_parser_label_declaration (parser)
- cp_parser *parser;
+cp_parser_label_declaration (cp_parser* parser)
{
/* Look for the `__label__' keyword. */
cp_parser_require_keyword (parser, RID_LABEL, "`__label__'");
@@ -13627,9 +13435,7 @@
TRUE. */

static tree
-cp_parser_lookup_name_simple (parser, name)
- cp_parser *parser;
- tree name;
+cp_parser_lookup_name_simple (cp_parser* parser, tree name)
{
return cp_parser_lookup_name (parser, name,
/*check_access=*/true,
@@ -13644,9 +13450,7 @@
extremely limited situations. */

static tree
-cp_parser_resolve_typename_type (parser, type)
- cp_parser *parser;
- tree type;
+cp_parser_resolve_typename_type (cp_parser* parser, tree type)
{
tree scope;
tree name;
@@ -13745,9 +13549,8 @@
and FALSE otherwise. */

static bool
-cp_parser_check_declarator_template_parameters (parser, declarator)
- cp_parser *parser;
- tree declarator;
+cp_parser_check_declarator_template_parameters (cp_parser* parser,
+ tree declarator)
{
unsigned num_templates;

@@ -13822,9 +13625,8 @@
return TRUE. */

static bool
-cp_parser_check_template_parameters (parser, num_templates)
- cp_parser *parser;
- unsigned num_templates;
+cp_parser_check_template_parameters (cp_parser* parser,
+ unsigned num_templates)
{
/* If there are more template classes than parameter lists, we have
something like:
@@ -13864,10 +13666,9 @@
the two sub-expressions. */

static tree
-cp_parser_binary_expression (parser, token_tree_map, fn)
- cp_parser *parser;
- const cp_parser_token_tree_map token_tree_map;
- cp_parser_expression_fn fn;
+cp_parser_binary_expression (cp_parser* parser,
+ const cp_parser_token_tree_map token_tree_map,
+ cp_parser_expression_fn fn)
{
tree lhs;

@@ -13919,9 +13720,7 @@
present, and NULL_TREE otherwise. */

static tree
-cp_parser_global_scope_opt (parser, current_scope_valid_p)
- cp_parser *parser;
- bool current_scope_valid_p;
+cp_parser_global_scope_opt (cp_parser* parser, bool current_scope_valid_p)
{
cp_token *token;

@@ -14075,12 +13874,11 @@

static tree
cp_parser_function_definition_from_specifiers_and_declarator
- (parser, decl_specifiers, attributes, declarator, access_checks)
- cp_parser *parser;
- tree decl_specifiers;
- tree attributes;
- tree declarator;
- tree access_checks;
+ (cp_parser* parser,
+ tree decl_specifiers,
+ tree attributes,
+ tree declarator,
+ tree access_checks)
{
tree fn;
bool success_p;
@@ -14118,10 +13916,8 @@
Returns the function defined. */

static tree
-cp_parser_function_definition_after_declarator (parser,
- inline_p)
- cp_parser *parser;
- bool inline_p;
+cp_parser_function_definition_after_declarator (cp_parser* parser,
+ bool inline_p)
{
tree fn;
bool ctor_initializer_p = false;
@@ -14183,9 +13979,7 @@
is as for cp_parser_template_declaration. */

static void
-cp_parser_template_declaration_after_export (parser, member_p)
- cp_parser *parser;
- bool member_p;
+cp_parser_template_declaration_after_export (cp_parser* parser, bool member_p)
{
tree decl = NULL_TREE;
tree parameter_list;
@@ -14263,12 +14057,9 @@
*FRIEND_P is set to TRUE iff the declaration is a friend. */

static tree
-cp_parser_single_declaration (parser,
- member_p,
- friend_p)
- cp_parser *parser;
- bool member_p;
- bool *friend_p;
+cp_parser_single_declaration (cp_parser* parser,
+ bool member_p,
+ bool* friend_p)
{
bool declares_class_or_enum;
tree decl = NULL_TREE;
@@ -14346,9 +14137,7 @@
representing the cast. */

static tree
-cp_parser_functional_cast (parser, type)
- cp_parser *parser;
- tree type;
+cp_parser_functional_cast (cp_parser* parser, tree type)
{
tree expression_list;

@@ -14372,9 +14161,7 @@
parse them now. */

static void
-cp_parser_late_parsing_for_member (parser, member_function)
- cp_parser *parser;
- tree member_function;
+cp_parser_late_parsing_for_member (cp_parser* parser, tree member_function)
{
cp_lexer *saved_lexer;

@@ -14503,9 +14290,7 @@
encountered. */

static tree
-cp_parser_sizeof_operand (parser, keyword)
- cp_parser *parser;
- enum rid keyword;
+cp_parser_sizeof_operand (cp_parser* parser, enum rid keyword)
{
static const char *format;
tree expr = NULL_TREE;
@@ -14598,8 +14383,7 @@
Returns TRUE iff `friend' appears among the DECL_SPECIFIERS. */

static bool
-cp_parser_friend_p (decl_specifiers)
- tree decl_specifiers;
+cp_parser_friend_p (tree decl_specifiers)
{
while (decl_specifiers)
{
@@ -14622,10 +14406,9 @@
Otherwise, returns NULL. */

static cp_token *
-cp_parser_require (parser, type, token_desc)
- cp_parser *parser;
- enum cpp_ttype type;
- const char *token_desc;
+cp_parser_require (cp_parser* parser,
+ enum cpp_ttype type,
+ const char* token_desc)
{
if (cp_lexer_next_token_is (parser->lexer, type))
return cp_lexer_consume_token (parser->lexer);
@@ -14643,10 +14426,9 @@
the next token is not as expected. */

static void
-cp_parser_skip_until_found (parser, type, token_desc)
- cp_parser *parser;
- enum cpp_ttype type;
- const char *token_desc;
+cp_parser_skip_until_found (cp_parser* parser,
+ enum cpp_ttype type,
+ const char* token_desc)
{
cp_token *token;
unsigned nesting_depth = 0;
@@ -14692,10 +14474,9 @@
Otherwise, returns NULL. */

static cp_token *
-cp_parser_require_keyword (parser, keyword, token_desc)
- cp_parser *parser;
- enum rid keyword;
- const char *token_desc;
+cp_parser_require_keyword (cp_parser* parser,
+ enum rid keyword,
+ const char* token_desc)
{
cp_token *token = cp_parser_require (parser, CPP_KEYWORD, token_desc);

@@ -14719,8 +14500,7 @@
function-definition. */

static bool
-cp_parser_token_starts_function_definition_p (token)
- cp_token *token;
+cp_parser_token_starts_function_definition_p (cp_token* token)
{
return (/* An ordinary function-body begins with an `{'. */
token->type == CPP_OPEN_BRACE
@@ -14748,8 +14528,7 @@
or none_type otherwise. */

static enum tag_types
-cp_parser_token_is_class_key (token)
- cp_token *token;
+cp_parser_token_is_class_key (cp_token* token)
{
switch (token->keyword)
{
@@ -14852,8 +14631,7 @@
tokens. */

static void
-cp_parser_parse_tentatively (parser)
- cp_parser *parser;
+cp_parser_parse_tentatively (cp_parser* parser)
{
/* Enter a new parsing context. */
parser->context = cp_parser_context_new (parser->context);
@@ -14868,8 +14646,7 @@
/* Commit to the currently active tentative parse. */

static void
-cp_parser_commit_to_tentative_parse (parser)
- cp_parser *parser;
+cp_parser_commit_to_tentative_parse (cp_parser* parser)
{
cp_parser_context *context;
cp_lexer *lexer;
@@ -14891,8 +14668,7 @@
will be rolled back, and no diagnostics will be issued. */

static void
-cp_parser_abort_tentative_parse (parser)
- cp_parser *parser;
+cp_parser_abort_tentative_parse (cp_parser* parser)
{
cp_parser_simulate_error (parser);
/* Now, pretend that we want to see if the construct was
@@ -14905,8 +14681,7 @@
Returns true if no error occurred; false otherwise. */

static bool
-cp_parser_parse_definitely (parser)
- cp_parser *parser;
+cp_parser_parse_definitely (cp_parser* parser)
{
bool error_occurred;
cp_parser_context *context;
@@ -14951,8 +14726,7 @@
we will stick with this tentative parse, even if errors occur. */

static bool
-cp_parser_committed_to_tentative_parse (parser)
- cp_parser *parser;
+cp_parser_committed_to_tentative_parse (cp_parser* parser)
{
return (cp_parser_parsing_tentatively (parser)
&& parser->context->status == CP_PARSER_STATUS_KIND_COMMITTED);
@@ -14962,8 +14736,7 @@
tentative parse. */

static bool
-cp_parser_error_occurred (parser)
- cp_parser *parser;
+cp_parser_error_occurred (cp_parser* parser)
{
return (cp_parser_parsing_tentatively (parser)
&& parser->context->status == CP_PARSER_STATUS_KIND_ERROR);
@@ -14972,8 +14745,7 @@
/* Returns non-zero if GNU extensions are allowed. */

static bool
-cp_parser_allow_gnu_extensions_p (parser)
- cp_parser *parser;
+cp_parser_allow_gnu_extensions_p (cp_parser* parser)
{
return parser->allow_gnu_extensions_p;
}
@@ -14989,7 +14761,7 @@
/* Parse the entire translation unit. */

int
-yyparse ()
+yyparse (void)
{
bool error_occurred;

@@ -15003,7 +14775,7 @@
/* Clean up after parsing the entire translation unit. */

void
-free_parser_stacks ()
+free_parser_stacks (void)
{
/* Nothing to do. */
}

[Zack Weinberg]

Post by Nathanael Nerode
Bootstrapped on i686-pc-linux-gnu. OK to commit?
I'm doing these one file at a time because they're *huge* (and because I
have to do most of it by hand). I'm asking
for approval because the ANSIfication of the function defintions (the
way formal parameters are specified) doesn't appear to fall under the
'obvious' rule. If someone says it does, I'll start putting these in
as soon as they bootstrap. :-)

I have ambitions of applying the new parser to C as well as C++;
therefore I would appreciate this *not* being applied, unless we are
going to reexamine the requirement for K+R C in the C front end.

zw

[Neil Booth]

Zack Weinberg wrote:-

Post by Zack Weinberg

Post by Nathanael Nerode
Bootstrapped on i686-pc-linux-gnu. OK to commit?
I'm doing these one file at a time because they're *huge* (and because I
have to do most of it by hand). I'm asking
for approval because the ANSIfication of the function defintions (the
way formal parameters are specified) doesn't appear to fall under the
'obvious' rule. If someone says it does, I'll start putting these in
as soon as they bootstrap. :-)

I have ambitions of applying the new parser to C as well as C++;
therefore I would appreciate this *not* being applied, unless we are
going to reexamine the requirement for K+R C in the C front end.

Are you going to do that?

I'll say again that I think a combined C and C++ parser is a mistake;
it penalizes C in so many ways.

Neil.

[Gabriel Dos Reis]

Neil Booth <***@daikokuya.co.uk> writes:

| I'll say again that I think a combined C and C++ parser is a mistake;
| it penalizes C in so many ways.

I'm not sure it is a mistake; but I believe it is a very premature
thing for 3.4 (even for 3.5).

-- Gaby

[Kaveh R. Ghazi]

From: Gabriel Dos Reis <gdr at integrable-solutions dot net>
| I'll say again that I think a combined C and C++ parser is a mistake;
| it penalizes C in so many ways.

I'm confident that Zack would provide some positive performance
analysis before submitting such a change for consideration.

I'm not sure it is a mistake; but I believe it is a very premature
thing for 3.4 (even for 3.5).
-- Gaby

I guess that depends on how fast it gets done. :-)

--Kaveh
--
Kaveh R. Ghazi ***@caip.rutgers.edu

[Gabriel Dos Reis]

"Kaveh R. Ghazi" <***@caip.rutgers.edu> writes:

| > I'm not sure it is a mistake; but I believe it is a very premature
| > thing for 3.4 (even for 3.5).
| > -- Gaby
|
| I guess that depends on how fast it gets done. :-)

My point is that changing the parser is a destabilizing process, even
though we _hope_ that for the long run that is the Right Road.

At this point, we need first to consolidate the great work done by
Mark, resolve regressions, pending issues. Since the C front-end is
so crucial, I would suggest we don't do it in the hurry. That does
not mean I don't trust Zack's skills -- that has nothing to do with
that.

-- Gaby

[Mark Mitchell]

Post by Gabriel Dos Reis
At this point, we need first to consolidate the great work done by
Mark, resolve regressions, pending issues. Since the C front-end is
so crucial, I would suggest we don't do it in the hurry. That does
not mean I don't trust Zack's skills -- that has nothing to do with
that.

I tend to agree. I'm sure there are still bugs in the new parser, and
adding C support will only increase that.

The path to follow, in my opinion, is to implement C support in the
new parser, and C support in the C++ front-end, while still
preserving the C front end.

I don't think the big win in eventually converting the C++ front end to
be a combined C/C++ front end will be performance -- it will be
elimination of many thousands of lines of code, and numerous
inconsistencies between the front ends. It will also make it much
easier to support C99 features in C++, and use some parts of the
C++ front end (like templates and/or overloading) to implement things
like Altivec and generic match support.

People are right to be concerned about the performance impact, and we'll
need to speed up the C++ front end a good bit. Fortunately, this is
going to be one of our major areas of focus, now that the new parser
is (mostly) out of the way.

[Mike Stump]

Post by Mark Mitchell
The path to follow, in my opinion, is to implement C support in the
new parser, and C support in the C++ front-end, while still
preserving the C front end.

Hum, then I think we (Apple) should contribute Objective-C++, as
otherwise, if we ever switch to bundling C into the C++ compiler, we'd
be out an existing language that we want going forward.

[Mark Mitchell]

--On Thursday, January 09, 2003 12:15:29 PM -0800 Mike Stump

Post by Mike Stump

Post by Mark Mitchell
The path to follow, in my opinion, is to implement C support in the
new parser, and C support in the C++ front-end, while still
preserving the C front end.

Hum, then I think we (Apple) should contribute Objective-C++, as
otherwise, if we ever switch to bundling C into the C++ compiler, we'd be
out an existing language that we want going forward.

Or you might get it "for free"; as far as I know there are no plans to
drop Objective-C, so before the current C compiler could go away, we'd
need Objective-C (as well as plain C) in the C++ front end.

--
Mark Mitchell ***@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com

[Neil Booth]

Neil Booth wrote:-

Post by Neil Booth
Are you going to do that?
I'll say again that I think a combined C and C++ parser is a mistake;
it penalizes C in so many ways.

Well, I don't seem to have much support in this belief. However, I do
believe it, and so I'm going to put the effort in and do it.

Since the new C++ parser went in, I've started to think I can see
the light at the end of the tunnel to having really high quality C and
C++ front ends (I don't believe we have those at present).

I got quite enthusiastic, and was so convinced that a separate C parser
is the right thing that I started one last weekend. My plan was/is as
follows:

o Create a re-entrant recursive descent parser that looks somewhat
like cp/parser.c, in gcc/parser.c.
o Have no target-dependence at all, apart from target types and struct
layout requirements.
o Have it generate a simple, high-level C IR (with real types, not the
"everything is a tree" paradigm) that doesn't lose any information
from the source or perform any simplifications or optimizations, and
do complete C99 syntactic and semantic checking on it. The last 3
years have convinced me we're not going to get a correct, ICE-free,
confused-by-earlier-errors-and-bailing-out-free C or C++ front end
with trees as our top-level IR. They simply try to be everything to
every front end, and let each down badly. Bison only serves to
aggravate the complexity IMO.
o Have a separate file lower.c that lowers the C IR to the intermediate
IR, most probably doing basic simplifications at the same time. That
IR is currently trees but I'd rather GIMPLE if and when that appears.
o Later, add ObjC and GCC extensions; I'm not sure which first.
o My target is to have all the above (excl. lowering?) take the same
amount of time as preprocessing, with some slack to a maximum of 150%
of CPP time. I think this a tough target, but not unreasonable.
We're currently between 400% and 700% on most source files I believe.

I have already written the skeleton parser; it currently parses
declarations (except function prototypes - I got bored of decls and
started expressions 8)) and expressions to the C99 grammar. Grammar-wise
that leaves mainly statements. There is little/no syntactic or semantic
analysis, but they appear to be straight forward. It is never necessary
to look further ahead than the current token, so there is no backtracking.
I'm already convinced that non-trees truly are the way to go: the C IR
is simple and straight-forward, and I can use all the same terminology
that the standard uses to describe constructs. This makes reading the
source easier. Things that we currently fail to do right, like C99
integer constant expressions, integer rank, etc. with no sign of a fix
on the horizon, drop out easily.

Other things I've noticed: constant folding should be separate from
folding for optimization or rearrangement. fold() does both and is large
and complex as a result. Also, my ideas for a better preprocessor /
C family front end interface were not the right ones. Also, it is easy
to add just that little bit of context-sensitivity to a recursive
descent parser that bison cannot have, that makes so many things so much
simpler and cleaner (witness the declspecs horror of c-parse.in, for but
a single example).

If we're going to have a combined C/C++ parser, then I want it to be
competitive performance-wise, maintenance-wise and quality-wise with
one that doesn't have to handle C++. So I want to provide one that does
so as a comparison. If my little project is not accepted, but to be
rejected it forces a really good combined parser, it will have achieved
my goal and I will have learned something. I intend to set a high bar.

Just to let y'all know. If it starts to look promising, I'll make a
branch. Of course, I may never finish it. ;}

Neil.

[Vladimir Makarov]

Post by Neil Booth
Neil Booth wrote:-

Post by Neil Booth
Are you going to do that?
I'll say again that I think a combined C and C++ parser is a mistake;
it penalizes C in so many ways.

Well, I don't seem to have much support in this belief. However, I do
believe it, and so I'm going to put the effort in and do it.

I do believe it too. I don't want to start a flame. With my point of
view the combined parser is reflection of the belief that nobody is
interested in only C compiler and the most people is interested in
C/C++. C++ started as a small extension of C and now C is a tiny part
of C++. If this belief is not true, than the separate C front-end
results in more manageable and reliable C front-end.

Post by Neil Booth
Since the new C++ parser went in, I've started to think I can see
the light at the end of the tunnel to having really high quality C and
C++ front ends (I don't believe we have those at present).
I got quite enthusiastic, and was so convinced that a separate C parser
is the right thing that I started one last weekend. My plan was/is as
o Create a re-entrant recursive descent parser that looks somewhat
like cp/parser.c, in gcc/parser.c.

Do you use a compiler-compiler? If you are writing it manually (usging
recursive functions), then how are you going to implement syntactic
error recovery? What quality of the recovery do you can achieve this
way?

IMHO, you can not achieve a good syntactic error recover without an
explicit parser stack. Also I think that the current computers permit
to implement a minimal cost error recovery now (actually the slowdown
occurs if a syntax error is found). Such implementation needs a
backtracking to evaluate different alternatives of the recovery.

Also it is good to have C parser as an abstract component. It could use
it not only for gcc (it might result in creation of another free C
compiler -- it is good for gcc to have another free c compiler as a
competitor).

You can ignore these ideas and questions - it is your implementation. I
know how front-end implementation is difficult and boring.

Vlad

[Neil Booth]

Vladimir Makarov wrote:-

Post by Vladimir Makarov
I do believe it too. I don't want to start a flame. With my point of
view the combined parser is reflection of the belief that nobody is
interested in only C compiler and the most people is interested in
C/C++. C++ started as a small extension of C and now C is a tiny part
of C++. If this belief is not true, than the separate C front-end
results in more manageable and reliable C front-end.

Agreed. I'm not anti-C++, I just want the best C and C++ front ends
possible.

Post by Vladimir Makarov
Do you use a compiler-compiler? If you are writing it manually (usging
recursive functions), then how are you going to implement syntactic
error recovery? What quality of the recovery do you can achieve this
way?

I think reasonably good recovery is possible. Just because something
is recursive descent doesn't mean you have to make it textbook 100%
recursive descent. For example, my current expression parser unifies all
of cast-expression, unary-expression and primary-expression, but keeps
postfix-expression separate, because that makes it easy to handle a
'(', which can start 3 things: parenthesized expression, a compound
literal, or a cast. Without unification you need backtracking or
something nasty.

However, I've not seen what error recovery is like, because I'm nothing
like that far yet 8-) However, do you think the EDG front end's give
bad diagnostics? IMO they're better than any other compiler I've seen
and they use RD.

Post by Vladimir Makarov
IMHO, you can not achieve a good syntactic error recover without an
explicit parser stack. Also I think that the current computers permit
to implement a minimal cost error recovery now (actually the slowdown
occurs if a syntax error is found). Such implementation needs a
backtracking to evaluate different alternatives of the recovery.

Let's see.

Post by Vladimir Makarov
Also it is good to have C parser as an abstract component. It could use
it not only for gcc (it might result in creation of another free C
compiler -- it is good for gcc to have another free c compiler as a
competitor).

Indeed. I think GCC needs competition; it's getting a bit fat and lazy.

Post by Vladimir Makarov
You can ignore these ideas and questions - it is your implementation. I
know how front-end implementation is difficult and boring.

Au contraire, I'm finding it fun and interesting. But I've not done it
before, and I've not studied CS, so it's not old-hat to me.

Neil.

[Mark Mitchell]

--On Thursday, January 09, 2003 10:14:33 PM +0000 Neil Booth

Post by Neil Booth
Vladimir Makarov wrote:-

Post by Vladimir Makarov
I do believe it too. I don't want to start a flame. With my point of
view the combined parser is reflection of the belief that nobody is
interested in only C compiler and the most people is interested in
C/C++. C++ started as a small extension of C and now C is a tiny part
of C++. If this belief is not true, than the separate C front-end
results in more manageable and reliable C front-end.

Agreed. I'm not anti-C++, I just want the best C and C++ front ends
possible.

The EDG front end is the best C++ front end, from a technical point of
view, and it is also a very good C front end. (There are other very
good C front ends, too, including the one in GCC.)

The EDG front end is a combined C/C++ front end; it shares a very large
amount of code between C and C++, including the parser, with great
success. To me, that is a compelling existence proof.

Of course, much of the C++ front end will be totally unused in C.

[Stan Shebs]

Post by Mark Mitchell
The EDG front end is the best C++ front end, from a technical point of
view, and it is also a very good C front end. (There are other very
good C front ends, too, including the one in GCC.)
The EDG front end is a combined C/C++ front end; it shares a very large
amount of code between C and C++, including the parser, with great
success. To me, that is a compelling existence proof.

Another compelling example is CodeWarrior, which has a combined
C/C++/ObjC frontend, and even so manages to be an order of
magnitude faster at compiling straight vanilla code, no PCH or
preloading or other trickery.

So if we can't make GCC fast using a combined frontend, it's because
we're lame, not because it's technically infeasible. (And to lose
to a bunch of Mac hackers, oh the shame. :-) )

Stan

PS Amusingly, GCC is faster than CW at high optimization levels
on large functions. I'm sure it's just a coincidence that GCC's
own sources include many large functions. :-)

[Toon Moene]

Post by Stan Shebs
PS Amusingly, GCC is faster than CW at high optimization levels
on large functions. I'm sure it's just a coincidence that GCC's
own sources include many large functions. :-)

No, that's a consequence of my '95-'97 work on optimizing large Fortran
routines [ REAL PROGRAMMERS WON'T GET CONFUSED BY
FIVE-PAGE-LONG-DO-LOOPS ] spilling over to C.

[Per Bothner]

Post by Neil Booth
o Later, add ObjC and GCC extensions; I'm not sure which first.

The existence of Objective-C++ does mean that ObjC extensions
would have to be added to both the C and C++ parsers. That is
an advantage to combining them.

In fact, there may be maintainance advantages to having a *single*
executable thta handles C, C++, ObjC and ObjC++.

Post by Neil Booth
If we're going to have a combined C/C++ parser, then I want it to be
competitive performance-wise, maintenance-wise and quality-wise with
one that doesn't have to handle C++.

I don't understand this goal when it comes to maintainance. Surely
what we want is to minimize the maintainance burden on the *combined*
compiler suite. That argues for combining code between the C and C++
compilers. Minimizing the complexity of the C compiler in isolation of
that means we have to duplicate work on the C++ compiler (which means
it doesn't get done) doesn't seem like a good tradeoff.

[Neil Booth]

Per Bothner wrote:-

Post by Per Bothner
In fact, there may be maintainance advantages to having a *single*
executable thta handles C, C++, ObjC and ObjC++.

Possibly; I agree there are advantages to combining. But I also think
there are disadvantages, and that the weight of the disadvantages fall
on C/ObjC.

I'd like to see a single GCC binary targeting multiple archs too, but that
would require a cleanup of GCC that looks a long long way off at present.

Post by Per Bothner
I don't understand this goal when it comes to maintainance. Surely
what we want is to minimize the maintainance burden on the *combined*
compiler suite. That argues for combining code between the C and C++
compilers. Minimizing the complexity of the C compiler in isolation of
that means we have to duplicate work on the C++ compiler (which means
it doesn't get done) doesn't seem like a good tradeoff.

I think an RD parser of C can be very small, efficient and simple to
understand. I do not think a C++ parser can be any of those, let alone
when it's handling C and ObjC as well. I hate to think of all the
ambiguities. C and C++ grammar is really quite different, to a parser
at least.

I'm willing to be persuaded otherwise, though, but by example. I don't
see what we've got to lose if I'm willing to do the work myself.

Neil.

[Per Bothner]

Post by Neil Booth
I'm willing to be persuaded otherwise, though, but by example. I don't
see what we've got to lose if I'm willing to do the work myself.

That is reasonable. But it might still be nice if the C and C++ parsers
can at least share some code - for example parsing expressions. That is
(potentionally) one advantage of a R/D parser. But that may be
difficult unless they have compatible APIs.

It would also be nice if the parser(s) were re-entrant, like cpplib.

[Zack Weinberg]

Post by Per Bothner

Post by Neil Booth
I'm willing to be persuaded otherwise, though, but by example. I don't
see what we've got to lose if I'm willing to do the work myself.

That is reasonable. But it might still be nice if the C and C++ parsers
can at least share some code - for example parsing expressions. That is
(potentionally) one advantage of a R/D parser. But that may be
difficult unless they have compatible APIs.

In fact code sharing was the major reason why I suggested unifying the
C and C++ front ends. But I'm not dogmatic - whatever works is great
by me. Anyhow, I think the major area where sharing would be
worthwhile is in files like c-decl.c, not necessarily the parser
itself.

Post by Per Bothner
It would also be nice if the parser(s) were re-entrant, like cpplib.

Yes, except that there has never been a user of cpplib's notional
reentrancy and therefore we don't know if it actually works. I'm
inclined to call YAGNI.

zw

[Neil Booth]

Zack Weinberg wrote:-

Post by Zack Weinberg

Post by Per Bothner
It would also be nice if the parser(s) were re-entrant, like cpplib.

Yes, except that there has never been a user of cpplib's notional
reentrancy and therefore we don't know if it actually works. I'm
inclined to call YAGNI.

YAGNI? Yet another good? ...?

I'm writing mine like Mark did his; it will be re-entrant. Unlike
cpplib parsers are recursive, so it is more obviously useful in this
case.

Neil.

[Zack Weinberg]

Post by Neil Booth
Zack Weinberg wrote:-

Post by Zack Weinberg

Post by Per Bothner
It would also be nice if the parser(s) were re-entrant, like cpplib.

Yes, except that there has never been a user of cpplib's notional
reentrancy and therefore we don't know if it actually works. I'm
inclined to call YAGNI.

YAGNI? Yet another good? ...?

"You aren't gonna need it." They say it a lot over on python-dev.

Basically, if reentrancy falls out of the algorithm, like it sounds
like it might, great; but I wouldn't sweat trying to make it be
reentrant if things turn out otherwise.

zw

[Ziemowit Laski]

Post by Per Bothner

Post by Neil Booth
I'm willing to be persuaded otherwise, though, but by example. I don't
see what we've got to lose if I'm willing to do the work myself.

That is reasonable. But it might still be nice if the C and C++ parsers
can at least share some code - for example parsing expressions. That is
(potentionally) one advantage of a R/D parser. But that may be
difficult unless they have compatible APIs.

Actually, one possible approach would be to take Mark's C++ parser and
grow it "down and sideways" to also accept C and Objective-C (and hence
Objective-C++). I think that "merging" the C and C++ worlds as they
currently exist would be far more difficult because of the API
differences
(which can be quite subtle and gnarly, as I've discovered when doing
Apple's current ObjC++ implementation).

As always, my 2 zlotys,

--Zem
--------------------------------------------------------------
Ziemowit Laski 1 Infinite Loop, MS 301-2K
Mac OS X Compiler Group Cupertino, CA USA 95014-2083
Apple Computer, Inc. +1.408.974.6229 Fax .5477

[Gabriel Dos Reis]

Neil Booth <***@daikokuya.co.uk> writes:

| Per Bothner wrote:-
|
| > In fact, there may be maintainance advantages to having a *single*
| > executable thta handles C, C++, ObjC and ObjC++.
|
| Possibly; I agree there are advantages to combining. But I also think
| there are disadvantages, and that the weight of the disadvantages fall
| on C/ObjC.

Well, I do believe that the "code duplication" issue is a realistic
and killer argument. We have datapoints showing how that beats us in
the past (and present). However, wouldn't it be possible to set up
machinery to share codes between those front-ends?

-- Gaby

[Mark Mitchell]

--On Friday, January 10, 2003 01:33:08 PM +0100 Gabriel Dos Reis

Post by Gabriel Dos Reis
Well, I do believe that the "code duplication" issue is a realistic
and killer argument. We have datapoints showing how that beats us in
the past (and present). However, wouldn't it be possible to set up
machinery to share codes between those front-ends?

The problem with the c-common strategy is that we have to keep trying
to refactor code that doesn't need to be refactored -- just reused.

As a small example, consider the C++ code that handles variables going
out of scope. It checks for a destructor, and if there is one, runs
a cleanup. Well, that will work fine in C -- there are no destructors.
If profiling shows those checks to be expensive, conditionalize the
function. But, there's no reason to use function-pointers and callbacks
and so forth to move most of the code into c-common.

Declarators are perhaps a better example. If we really do create a
sensible declarator data-structure there's no point putting it in
c-common, and then having lots of shared code for processing them, but
then extra bits for C++ constructs like qualified names and
pointers-to-members. The right thing to do is simply to use the same
code, but not check for qualified names or pointers-to-members in C.

[Gabriel Dos Reis]

Mark Mitchell <***@codesourcery.com> writes:

[...]

| As a small example, consider the C++ code that handles variables going
| out of scope. It checks for a destructor, and if there is one, runs
| a cleanup. Well, that will work fine in C -- there are no destructors.
| If profiling shows those checks to be expensive, conditionalize the
| function. But, there's no reason to use function-pointers and callbacks
| and so forth to move most of the code into c-common.

I find that quite definitively convincing argument.

Thanks,

-- Gaby

[Joseph S. Myers]

Post by Mark Mitchell
The problem with the c-common strategy is that we have to keep trying
to refactor code that doesn't need to be refactored -- just reused.
As a small example, consider the C++ code that handles variables going
out of scope. It checks for a destructor, and if there is one, runs
a cleanup. Well, that will work fine in C -- there are no destructors.
If profiling shows those checks to be expensive, conditionalize the
function. But, there's no reason to use function-pointers and callbacks
and so forth to move most of the code into c-common.
Declarators are perhaps a better example. If we really do create a
sensible declarator data-structure there's no point putting it in
c-common, and then having lots of shared code for processing them, but
then extra bits for C++ constructs like qualified names and
pointers-to-members. The right thing to do is simply to use the same
code, but not check for qualified names or pointers-to-members in C.

(a) Small functions are good. grokdeclarator could do with having lots of
small helper functions split off in order to make it more comprehensible.
If these handle C++-specific cases, it's hardly a problem to have a C
version with the same name that just does abort(). (But the tree codes
and some macros may need to be shared for grokdeclarator to be.)

(b) Incremental changes are good. With a few changes to facilitate
sharing (e.g. making tree codes common, making some macros and data
structures common [0]), functions can be shared one at a time, the
benefits of the shared code can be immediate, and each newly shared
function gets more general testing and debugging.

[0] If this doesn't cause efficiency problems or increased memory
consumption for C. Such costs are balanced against the function call
costs for dummy functions such as identifier_global_value which just
exists to call IDENTIFIER_GLOBAL_VALUE.

(c) Littering code with complicated if (C) conditionals is bad. Instead
of "if (C) { lots of code for C } else { lots of code for C++ }", better
call a function foo() which does something well-defined depending on the
language - which can now be implemented separately for C and C++ (one
possibly being an abort() only). A merged front end can just define foo()
to be "if (C) foo_c(); else foo_cpp();" and later simplify cases where one
was an abort and pull back some performance-critical ifs into the calling
functions - but with proper incremental development, a merger patch should
be quite simple.

[Neil Booth]

Per Bothner wrote:-

Post by Per Bothner

Post by Neil Booth
o Later, add ObjC and GCC extensions; I'm not sure which first.

The existence of Objective-C++ does mean that ObjC extensions
would have to be added to both the C and C++ parsers. That is
an advantage to combining them.

b.t.w. I've repeatedly espoused sharing a lot of semantic and syntactic
analysis, just not the parsing. I think that applies here.

Neil.

[Neil Booth]

Per Bothner wrote:-

Post by Per Bothner
In fact, there may be maintainance advantages to having a *single*
executable thta handles C, C++, ObjC and ObjC++.

If you really mean executable, there's nothing stopping us having
2 different parsers in a single executable.

Neil.

[Per Bothner]

Post by Neil Booth
Per Bothner wrote:-

Post by Per Bothner
In fact, there may be maintainance advantages to having a *single*
executable thta handles C, C++, ObjC and ObjC++.

If you really mean executable,

I do. I'm not sure it would be the Right Thing, but I believe
there are existing compiler that use the same executable for C
and C++. It makes sense if you subscribe to the belief that
C is "mostly a superset of C", in which case you might as well
use the C++ compiler to compile C, just turn off C++-isms.
Rather like using the same executable to process both pre-processed
and non-preprocessed code.

But sharing source code of course the much more important goal.

Post by Neil Booth
there's nothing stopping us having
2 different parsers in a single executable.

True, but that would reduce the point of using a single executable.

[Nicola Pero]

Post by Per Bothner

Post by Neil Booth
o Later, add ObjC and GCC extensions; I'm not sure which first.

The existence of Objective-C++ does mean that ObjC extensions
would have to be added to both the C and C++ parsers. That is
an advantage to combining them.

The Objective-C extensions are very simple, so I don't think this would be
a particular problem.

Post by Per Bothner

Post by Neil Booth
If we're going to have a combined C/C++ parser, then I want it to be
competitive performance-wise, maintenance-wise and quality-wise with
one that doesn't have to handle C++.

I don't understand this goal when it comes to maintainance. Surely
what we want is to minimize the maintainance burden on the *combined*
compiler suite. That argues for combining code between the C and C++
compilers. Minimizing the complexity of the C compiler in isolation of
that means we have to duplicate work on the C++ compiler (which means
it doesn't get done) doesn't seem like a good tradeoff.

Yes - a single codebase can mean with a single patch you could fix/update
both the ObjC/C and ObjC++/C++ parsers. But that's not the point. The
point is: would that single patch be easier or more complex to write than
two separated patches, one for the ObjC/C parser, and another one for the
ObjC++/C++ parsers ?

Simpler software is easier to maintain and easier to understand. Merging
together two big and complex pieces of software does usually result in a
piece of software which is more complex than the original pieces.

People who could read a ObjC/C parser, and help with it, might not have
the time and skills and experience to read and help with a much more
complex integrated parser for C++/C/ObjC/ObjC++.

As free software benefits a lot from occasional contributors, I think
having very simple and readable source code (where the occasional
contributor can easily find its way around, and contribute) should be one
of the basic design principles.

This is one of the basic problems of GCC - the source code of GCC is
unreadable and horribly complex for the occasional contributor.

I don't believe it's because compilers are complex. It's because it's not
well designed/written.

I've seen a lot of improvements, and I see a lot of great people working
on it and making it better - but it's still very difficult to read and I
often wonder if to get to a readable software the only solution wouldn't
be to just write a new compiler from scratch, using a proper clean OO
design.

Anyway, merging the C/ObjC and C++/ObjC++ parsers might look very nice,
but to me it looks like it will make a situation of unreadable,
complicated code with too many enumerated cases, exceptions, subcases,
obscure sub-sub-sub-exceptions even worse.

It will raise a lot the minimum level of time and GCC/compiler experience
required for even minimal contributions to the C/ObjC front-end.

Basically, we won't be able to suggest changes to the C/ObjC front-end
without knowing also about the C++/ObjC++ front-end (which is a much more
complicated language/parser as far as I know).

IMO that is definitely bad.

[Devang Patel]

Post by Per Bothner

Post by Neil Booth
o Later, add ObjC and GCC extensions; I'm not sure which first.

The existence of Objective-C++ does mean that ObjC extensions
would have to be added to both the C and C++ parsers. That is
an advantage to combining them.
In fact, there may be maintainance advantages to having a *single*
executable thta handles C, C++, ObjC and ObjC++.

PCH brings one more reason to have one unified front end.

Here at Apple, typical large program is made up C as well as Objective-C
sources. Some of them have source files for all four language in one
project!
Usually one common set of large header is included in all source files.
Which means many PCHs (each around ~20 MBs) for one prefix header.
Not only space becomes one issue, but it also puts extra burden on build
system to make all of them.

-Devang

[Joseph S. Myers]

Post by Devang Patel
PCH brings one more reason to have one unified front end.
Here at Apple, typical large program is made up C as well as Objective-C
sources. Some of them have source files for all four language in one
project!
Usually one common set of large header is included in all source files.
Which means many PCHs (each around ~20 MBs) for one prefix header.
Not only space becomes one issue, but it also puts extra burden on build
system to make all of them.

A unified executable would hardly help here. If it were run cc1 -lang-c
versus cc1 -lang-objc ..., the option would affect many aspects of the
internal datastructures built up from the headers, and as PCH dumps these
datastructures, separate PCH files would be needed for each language.

[Devang Patel]

Post by Joseph S. Myers

Post by Devang Patel
PCH brings one more reason to have one unified front end.
Here at Apple, typical large program is made up C as well as
Objective-C
sources. Some of them have source files for all four language in one
project!
Usually one common set of large header is included in all source files.
Which means many PCHs (each around ~20 MBs) for one prefix header.
Not only space becomes one issue, but it also puts extra burden on build
system to make all of them.

A unified executable would hardly help here. If it were run cc1 -lang-c
versus cc1 -lang-objc ..., the option would affect many aspects of the
internal datastructures built up from the headers, and as PCH dumps these
datastructures, separate PCH files would be needed for each language.

Not necessarily. If it is done right way then there will not be
separate data
structures for each language affecting PCH as far as the prefix header
does not contain language dependent constructs. I am not saying it is
straightforward or easy.But If preprocessed output of header is
identical
for each language than one PCH should work in unified front end.

-Devang

[Joseph S. Myers]

Post by Devang Patel
Not necessarily. If it is done right way then there will not be
separate data
structures for each language affecting PCH as far as the prefix header
does not contain language dependent constructs. I am not saying it is
straightforward or easy.But If preprocessed output of header is
identical
for each language than one PCH should work in unified front end.

Preprocessed output is highly unlikely to be the same in useful cases for
C and C++, since the standard C headers use extern "C", put things in
namespace "std", etc. in C++ (and have other requirements in C++ different
from the requirements in C). Things might be more similar in some cases
between C and ObjC (are there any programs that are valid C and ObjC but
have different meanings in the two languages?) but you'd need some way for
PCH generation to tell "has flag_objc ever been tested in this
compilation?" to know whether the PCH file can be shared. I believe the
present approach is that a PCH file is specific to a precise combination
of compiler flags.

[Kai Henningsen]

Post by Joseph S. Myers
between C and ObjC (are there any programs that are valid C and ObjC but
have different meanings in the two languages?) but you'd need some way for

The way I understand it, every C program should also be an Objective C
program with the same meaning, possibly unless you try some weird tricks
with symbol pasting.

However, if you include one of the basic libobjc headers, you'll
immediately hit conditional compilation (for example, id will come out as
a different type for C or Objective C), and of course once you hit actual
Objective C syntax there's no longer valid C.

So, if you (for example) created a PCH with just Posix headers, that might
work.

MfG Kai

[Joseph S. Myers]

Post by Neil Booth
o Have it generate a simple, high-level C IR (with real types, not the
"everything is a tree" paradigm) that doesn't lose any information
from the source or perform any simplifications or optimizations, and
do complete C99 syntactic and semantic checking on it. The last 3

For this it makes more sense to convert the existing code to real types
rather than throwing it all away and starting over. In most places it is
clear which of expr/decl/type should be present (if a few cases are
cleaned up, e.g. the use of VAR_DECL direct in expressions to refer to the
expression referring to that variable).

(But fold() needs replacing with something that does just the folding
required by ISO C - keeping track of which sorts of constant expression
something is - and some optimisations in the present code need separating
from semantic analysis. The semantic analysis basically works (and
there's a lot more to do there than what's required by the standard, e.g.
many warnings are output at that stage, and some of these are broken by
the way optimisations are mixed with it).)

Post by Neil Booth
that leaves mainly statements. There is little/no syntactic or semantic
analysis, but they appear to be straight forward. It is never necessary

They also have functioning code that isn't anywhere near as fragile as the
parser.

Post by Neil Booth
source easier. Things that we currently fail to do right, like C99
integer constant expressions, integer rank, etc. with no sign of a fix
on the horizon, drop out easily.

Integer rank is trivial to do anyway. (I think the only case we get wrong
is mixing long and long long where both are the same size. Merge the code
with that from the C++ front end, which gets this case right.)

Integer constant expressions need several flags [0] to be carried with
each expression, and are complicated, subtle, and different in C90 and C99
(we couldn't decide in the UK C Panel whether this difference was a bug).
Also, WG14 didn't think DR#261 was a problem (but didn't, either, say
whether it describes the intended semantics - "the standard is clear
enough" in the Santa Cruz minutes without saying what the standard means).
We can't it seems [past discussion on comp.std.c] add to what counts as
each of the types of constant expression enumerated in the standard
(except through expressions that involve extensions - and we need
something like __constant__ to implement offsetof correctly when we're
strict about constant expressions). But we need to add some additional
type of constant expression, called "symbolic difference constant
expressions" in past discussions, that can be used in initializers, which
includes such things as ("foo" - "foo") and ("foo" + ("foo" - "foo")).
And getting -pedantic right here is a problem - in practice we need to be
strict about constant expressions if flag_iso because being strict can
both add and remove warnings.

[0] e.g. (int)1.0 is an integer constant expression, but (int)(double)1.0
is only an arithmetic constant expression. So a single flag for whether
something is constant does not suffice.

Post by Neil Booth
Other things I've noticed: constant folding should be separate from
folding for optimization or rearrangement. fold() does both and is large
and complex as a result. Also, my ideas for a better preprocessor /

And causes problems with correctness for constant expressions and
warnings. And causes similar problems for Java. In general it needs to
be rethought (probably through having languages use their own rules for
optimisations needed by the language, then the general optimisations
fold() does being done later on GIMPLE).

Post by Neil Booth
C family front end interface were not the right ones. Also, it is easy
to add just that little bit of context-sensitivity to a recursive
descent parser that bison cannot have, that makes so many things so much
simpler and cleaner (witness the declspecs horror of c-parse.in, for but
a single example).

The horrors of c-parse.in are the very fragile places where rules peek up
the parser stack ($<ttype>-1$ and similar), and then dummy actions are
needed in various places to ensure that what's wanted is always in the
right place up the stack. declspecs have lots of rules (to avoid
conflicts in the interests of maintainability) but they aren't fragile.

(ObjC has lots more parser conflicts than C. I don't know what grammar
bugs might be lurking there. The one advantage of a Bison parser is that
you can check the conflicts to be sure that adding a new grammar feature
doesn't cause a subtle parsing bug. But I believe the C99 grammar is now
feature-complete (everything's parsed, some things such as [*] arrays [1]
aren't implemented) so there shouldn't now be much need to add any new
features to the grammar.)

[1] [*] means that the array has size that is an indeterminate nonconstant
value of type size_t. Later uses of sizeof in the same function prototype
can refer to the size of such an array, and this is legitimate, so the
"indeterminate nonconstant" needs to be handled in expressions as part of
a proper C99 VLA implementation. This is probably the biggest part of
making C99 VLAs work; the concept of VM types is now in the compiler, just
needs to be hooked up to the diagnostics correctly, and checking
everything against every sentence C99 has about requirements for VLAs
(writing testcases in the process) is just tedious but necessary; I don't
expect many semantic changes to be needed in the process.

Post by Neil Booth
If we're going to have a combined C/C++ parser, then I want it to be
competitive performance-wise, maintenance-wise and quality-wise with
one that doesn't have to handle C++. So I want to provide one that does
so as a comparison. If my little project is not accepted, but to be
rejected it forces a really good combined parser, it will have achieved
my goal and I will have learned something. I intend to set a high bar.

The problem with a combined parser is that C and C++ aren't really similar
enough at the grammar level. C has a simple grammar that by design is
LALR(1) except for dangling else and typedef/identifier ambiguities that
are resolved in text in the standard (for some of these you need C90 +
TCs, since the removal of implicit int in C99 reduced the need for some
cases) rather than the grammar itself. C++ has a complicated grammar
that is very far from LALR(1) and needs the tentative parsing features of
the new parser - ambiguities are resolved in C++98 by saying that some
larger chunk of code is parsed in one way if it can, else in some other
way. A grammar full of if (C) conditionals is liable to be complicated,
confusing and unmaintainable.

Some parts of C and C++ are similar enough to share code, e.g. expressions
involving only ordinary C types, or grokdeclarator [2] which could do with
being shared with some if (C++) conditionals for C++-only features. In
more cases we could do with common interfaces to different code for C and
C++ (e.g. comptypes - takes a flags argument in C++ only) so that shared
code can use those interfaces. There are some parts that are so clearly
different that it only makes sense to have completely separate
implementations for C and C++ rather than if (C) conditionals - for
example, name lookup. And most of the C++ front end deals with features
that are only in C++ and so don't need conditionals. The grammar is
likely an area where C++ is sufficiently different from C for having loads
of if (C) conditionals to be bad.

[2] A nasty mess. As a comment in the new C++ parser notes, it should use
a sensible data structure rather than abusing trees to represent
declarators.

(But there are still C99 features it would be good to have implemented in
the C++ parser for the sake of header files - for example, the [restrict]
syntax for parameter array declarators, and the C99 syntax for designated
initializers.)

[Neil Booth]

Joseph S. Myers wrote:-

Post by Joseph S. Myers
The problem with a combined parser is that C and C++ aren't really similar
enough at the grammar level. C has a simple grammar that by design is
LALR(1) except for dangling else and typedef/identifier ambiguities that
are resolved in text in the standard (for some of these you need C90 +
TCs, since the removal of implicit int in C99 reduced the need for some
cases) rather than the grammar itself. C++ has a complicated grammar
that is very far from LALR(1) and needs the tentative parsing features of
the new parser - ambiguities are resolved in C++98 by saying that some
larger chunk of code is parsed in one way if it can, else in some other
way. A grammar full of if (C) conditionals is liable to be complicated,
confusing and unmaintainable.
Some parts of C and C++ are similar enough to share code, e.g. expressions
involving only ordinary C types, or grokdeclarator [2] which could do with
being shared with some if (C++) conditionals for C++-only features. In
more cases we could do with common interfaces to different code for C and
C++ (e.g. comptypes - takes a flags argument in C++ only) so that shared
code can use those interfaces. There are some parts that are so clearly
different that it only makes sense to have completely separate
implementations for C and C++ rather than if (C) conditionals - for
example, name lookup. And most of the C++ front end deals with features
that are only in C++ and so don't need conditionals. The grammar is
likely an area where C++ is sufficiently different from C for having loads
of if (C) conditionals to be bad.

Great! You're thinking pretty much like me. I just hate trees too, you
seem to be OK with them.

Post by Joseph S. Myers
[2] A nasty mess. As a comment in the new C++ parser notes, it should use
a sensible data structure rather than abusing trees to represent
declarators.

That's how I've done it.

Neil.

[Gabriel Dos Reis]

Neil Booth <***@daikokuya.co.uk> writes:

[ ... many things I generally agree with...]

| o Create a re-entrant recursive descent parser that looks somewhat
| like cp/parser.c, in gcc/parser.c.

Please, if you're going to "lift" the C front-end, please, first do
move the C front-end bits in a separate directory; just like
other front-ends. That would improve a bit the organization of the
files iin gcc/.

| o Have it generate a simple, high-level C IR (with real types, not the
| "everything is a tree" paradigm)

Yeah, the topic of going away from the "everything is a tree" paradigm
has been sporadically mentioned, but there seems to be no much thought
on it...

-- Gaby

[Neil Booth]

Gabriel Dos Reis wrote:-

Post by Gabriel Dos Reis
Please, if you're going to "lift" the C front-end, please, first do
move the C front-end bits in a separate directory; just like
other front-ends. That would improve a bit the organization of the
files iin gcc/.

OK, but that's not my highest priority.

Post by Gabriel Dos Reis
Yeah, the topic of going away from the "everything is a tree" paradigm
has been sporadically mentioned, but there seems to be no much thought
on it...

I believe it's 60% of the cause of GCC's current fragility, and that
reducing its influence or ridding ourselves of it entirely will help
improve GCC's quality tremendously.

Post by Gabriel Dos Reis
The problem with the c-common strategy is that we have to keep trying
to refactor code that doesn't need to be refactored -- just reused.
As a small example, consider the C++ code that handles variables going
out of scope. It checks for a destructor, and if there is one, runs
a cleanup. Well, that will work fine in C -- there are no destructors.
If profiling shows those checks to be expensive, conditionalize the
function. But, there's no reason to use function-pointers and callbacks
and so forth to move most of the code into c-common.
Declarators are perhaps a better example. If we really do create a
sensible declarator data-structure there's no point putting it in
c-common, and then having lots of shared code for processing them, but
then extra bits for C++ constructs like qualified names and
pointers-to-members. The right thing to do is simply to use the same
code, but not check for qualified names or pointers-to-members in C.

I agree 100%. But that is not the subject of this thread.

You're talking about sharing lowering code and / or semantic analysis.
Ever since this discussion first occurred 1 year ago that has been
my position too; I've repeated it in this thread already two or three
times. I think the C and C++ front ends can benefit tremendously from
a joint high-level IR that is specific to those languages and does
no simplification (that's key) before lowering to "tree" or "Gimple",
preferably the latter. The destructor thing you mention occurs during
lowering from a high-level IR to Gimple-level, and I agree that such
code should be 100% common. The declarator stuff is about sharing a
common high-level IR, and possibly code to create and analyze it.

This thread, however, is not about that. It's about a common parser.
C has many advantages over C++ when it comes to parsing, not least of
which is no need for backtracking, and I believe that it's much harder
to make a convincing case for a common parser than the arguments for
shared other things that you mention above. That is what I was aiming
at when I started this sub-thread. I want to make a separate parser,
if only to have a reference point to which we can compare any combined
parser that is written. To compare w.r.t. efficiency, comprehensibility
and maintainability, and even code size.

I've never claimed it's an existence argument; which you referred to in
another mail. EDG almost certainly does have a combined front end like
you state (unlike you I've not seen the source, obviously), and I can
believe such a beast is possible with some difficulty. However, that
front end has a reputation of being awfully slow - see the thread about
1 week ago where Mike Stump (I think?) posted a URL to a comparison of
g++, Code Warrior and Comeau (which uses EDG). Further, EDG doesn't
have ObjC to worry about.

I think the argument for a combined *parser* has to be much stronger than
"it is possible so we should do it". That isn't quite your position,
but I don't think it's too far different from your position either.
Nicola Pero gave some eloquent arguments in favour of a simpler C front
end in addition to arguments I've stated, which better express some of
my feelings and that I at least find quite compelling. The GCC project
has a strong interest in an efficient and easily maintained C front end,
which doesn't require high-guru status to contribute to, if only simply
because C is the most important language to GCC's target audience,
in addition to being our own and GNU's base language.

Let's agree to disagree about the parser for now, and see what develops.
Whatever happens, I am certain the C front ends have a brighter future than
appeared to be the case 18 months ago. That alone makes me very happy.

Neil.

[Nathanael Nerode]

Post by Neil Booth
Gabriel Dos Reis wrote:-

Post by Gabriel Dos Reis
Yeah, the topic of going away from the "everything is a tree" paradigm
has been sporadically mentioned, but there seems to be no much thought
on it...

I believe it's 60% of the cause of GCC's current fragility, and that
reducing its influence or ridding ourselves of it entirely will help
improve GCC's quality tremendously.

Here's a thought. :-)

Start by splitting the 'tree' type into a 'code tree' type and a
'declaration tree' type. The confusion between these two seems to me to
cause the most trouble. :-( They're also the two which actually need
some type of arbitrarily deep, polymorphic data structure; nothing else
does. Convert everything which isn't one of these (shouldn't be too
much) into other types.

For the first pass, the 'code tree' and 'declaration tree' types can be
intermungable to a certain extent, and we can try to disentangle them
bit by bit.

--Nathanael

[Joseph S. Myers]

Post by Nathanael Nerode
Here's a thought. :-)
Start by splitting the 'tree' type into a 'code tree' type and a
'declaration tree' type. The confusion between these two seems to me to
cause the most trouble. :-( They're also the two which actually need
some type of arbitrarily deep, polymorphic data structure; nothing else
does. Convert everything which isn't one of these (shouldn't be too
much) into other types.

There are at least three main kinds of tree that could do with static
typing - declarations, expressions and types. All of them can be
arbitrarily nested structures and can contain references to the other two.
There are also trees for statements in the C-family front ends, but there
have been objections that these duplicate generic trees and aren't needed.
There's also been discussion of slimming down identifiers.

Post by Nathanael Nerode
For the first pass, the 'code tree' and 'declaration tree' types can be
intermungable to a certain extent, and we can try to disentangle them
bit by bit.

We can (and I think should) do this incrementally, by starting with having
multiple types (decl_tree, expr_tree, type_tree, ...) which are all
actually typedefs for the current tree type. Code can be converted to use
these types, and more specific macros and functions for them, which
further code changes only needed where a function parameter, variable,
etc., can be more than one type of tree. These changes can be
incremental, making the actual change to static typing quite small.
Given static typing, the overhead of some of the runtime tree checks goes
away, and it's then possible to start slimming down these types (do most
trees really use all the pointer fields?, etc.) and cleaning up various
generic tree uses for which something else should be better, cases where
linked lists are inappropriately and inefficiently used, ....

[Joseph S. Myers]

Post by Zack Weinberg
I have ambitions of applying the new parser to C as well as C++;
therefore I would appreciate this *not* being applied, unless we are
going to reexamine the requirement for K+R C in the C front end.

The message I referred to
<http://gcc.gnu.org/ml/gcc/2002-06/msg00871.html> stated that

The committee intends to revisit this issue for the 3.3
series. Aside from the points already raised, one of the criteria
considered when this issue is brought up again may be whether
volunteers step forward to complete converting the portions we're
opening up now.

(where what was then 3.3 is now 3.4). So the SC should now be
reconsidering generally requiring at least a C90 compiler to bootstrap.
Note that we clearly have volunteers converting front ends now.

[Mike Stump]

Post by Zack Weinberg

Post by Nathanael Nerode
Bootstrapped on i686-pc-linux-gnu. OK to commit?
I'm doing these one file at a time because they're *huge* (and because I
have to do most of it by hand). I'm asking
for approval because the ANSIfication of the function defintions (the
way formal parameters are specified) doesn't appear to fall under the
'obvious' rule. If someone says it does, I'll start putting these in
as soon as they bootstrap. :-)

I have ambitions of applying the new parser to C as well as C++;
therefore I would appreciate this *not* being applied, unless we are
going to reexamine the requirement for K+R C in the C front end.

Sun dropped /bin/cc, and we managed. 10 years to take up a new
standard seems like plenty enough time, I say we announce that in 3.4
we mandate a C89+ compiler, and just do it. This will cause far fewer
problems, and those problems will be trivial to work around, when
compared to the new C++ parser, which we've already done.

[Neil Booth]

Mike Stump wrote:-

Post by Mike Stump
Sun dropped /bin/cc, and we managed. 10 years to take up a new
standard seems like plenty enough time, I say we announce that in 3.4
we mandate a C89+ compiler, and just do it. This will cause far fewer
problems, and those problems will be trivial to work around, when
compared to the new C++ parser, which we've already done.

Hear hear.

Neil.

[Phil Edwards]

Post by Neil Booth
Mike Stump wrote:-

Post by Mike Stump
Sun dropped /bin/cc, and we managed. 10 years to take up a new
standard seems like plenty enough time, I say we announce that in 3.4
we mandate a C89+ compiler, and just do it. This will cause far fewer
problems, and those problems will be trivial to work around, when
compared to the new C++ parser, which we've already done.

Hear hear.

Please, yes, for sanity's sake. The language has been standardized for
over a freaking decade. Any vendor still lagging behind and expecting the
rest of the world to slow down to meet them /deserves/ to fail by this point.


Phil

[Nathanael Nerode]

Post by Zack Weinberg

Post by Nathanael Nerode
Bootstrapped on i686-pc-linux-gnu. OK to commit?
I'm doing these one file at a time because they're *huge* (and because I
have to do most of it by hand). I'm asking
for approval because the ANSIfication of the function defintions (the
way formal parameters are specified) doesn't appear to fall under the
'obvious' rule. If someone says it does, I'll start putting these in
as soon as they bootstrap. :-)

I have ambitions of applying the new parser to C as well as C++;
therefore I would appreciate this *not* being applied, unless we are
going to reexamine the requirement for K+R C in the C front end.
zw

First of all, we clearly *are* going to reexamine it. It only exists
because HP still ships a K&R compiler by default with HPUX; this has to
end or become irrelevant sometime.

Second, the new parser code is already loaded with ANSI-isms. By
normalizing style, I believe this would actually make it easier to
de-ANSIfy it later using an automated tool.

--Nathanael

[Kaveh R. Ghazi]

From: Nathanael Nerode <neroden at twcny dot rr dot com>

Post by Zack Weinberg

Post by Nathanael Nerode
Bootstrapped on i686-pc-linux-gnu. OK to commit?
I'm doing these one file at a time because they're *huge* (and
because I have to do most of it by hand). I'm asking for approval
because the ANSIfication of the function defintions (the way formal
parameters are specified) doesn't appear to fall under the
'obvious' rule. If someone says it does, I'll start putting these
in as soon as they bootstrap. :-)

I have ambitions of applying the new parser to C as well as C++;
therefore I would appreciate this *not* being applied, unless we are
going to reexamine the requirement for K+R C in the C front end.
zw

First of all, we clearly *are* going to reexamine it. It only exists
because HP still ships a K&R compiler by default with HPUX; this has
to end or become irrelevant sometime.

IMHO approval for converting the core compiler is not guaranteed for
3.4 or 3.5, we need to carefully consider the needs of HP users versus
the maintenance burden of continuing K&R support.

However approval is more likely to be granted sonner rather than later
if the other parts already opened up for conversion are finished
first. Please keep it up! But I think you should save parser.c for
later or not at all as Zack requested and see what happens. At some
point, I'd like to see cp-tree.h undef and/or poison all the PARAMS
and other K&R support macros to keep it pure ISO C.

Second, the new parser code is already loaded with ANSI-isms. By
normalizing style, I believe this would actually make it easier to
de-ANSIfy it later using an automated tool.
--Nathanael

Using something like ansi2knr is interesting and might be doable but I
don't think it's trivial to use it in GCC given the complexity, size
and the 3-stage support we'd need.

Perhaps automake can help? Does anyone think adding automake
conversion of the gcc dir and ansi2knr as two new beginner projects is
worthwhile?

--Kaveh
--
Kaveh R. Ghazi ***@caip.rutgers.edu

[Gabriel Dos Reis]

"Kaveh R. Ghazi" <***@caip.rutgers.edu> writes:

| However approval is more likely to be granted sonner rather than later
| if the other parts already opened up for conversion are finished
| first. Please keep it up!

Seconded.

| But I think you should save parser.c for
| later or not at all as Zack requested and see what happens. At some
| point, I'd like to see cp-tree.h undef and/or poison all the PARAMS
| and other K&R support macros to keep it pure ISO C.

I believe that merging the C and C++ parsers for 3.4 or 3.5 is really
premature. Holding the ansification of cp/ until 3.6 is unreasanoble;
therefore I would strongly suggest the patch be applied. By the
time we would like to merge the front-ends, I think the K&R issue will
be moot, i.e. we will be already on road of requiring C90.

-- Gaby

[Kaveh R. Ghazi]

Post by Gabriel Dos Reis
| But I think you should save parser.c for
| later or not at all as Zack requested and see what happens. At some
| point, I'd like to see cp-tree.h undef and/or poison all the PARAMS
| and other K&R support macros to keep it pure ISO C.
I believe that merging the C and C++ parsers for 3.4 or 3.5 is really
premature. Holding the ansification of cp/ until 3.6 is unreasanoble;

I certainly didn't suggest holding up the entire cp directory!
Doing (just) parser.c later (or simply last) isn't unreasonable IMHO.

--Kaveh

PS: I'm going to help do some of the obvious conversions. :-)

--
Kaveh R. Ghazi ***@caip.rutgers.edu

[Gabriel Dos Reis]

"Kaveh R. Ghazi" <***@caip.rutgers.edu> writes:

| > From: Gabriel Dos Reis <***@integrable-solutions.net>
| >
| > | But I think you should save parser.c for
| > | later or not at all as Zack requested and see what happens. At some
| > | point, I'd like to see cp-tree.h undef and/or poison all the PARAMS
| > | and other K&R support macros to keep it pure ISO C.
| >
| > I believe that merging the C and C++ parsers for 3.4 or 3.5 is really
| > premature. Holding the ansification of cp/ until 3.6 is unreasanoble;
|
| I certainly didn't suggest holding up the entire cp directory!
| Doing (just) parser.c later (or simply last) isn't unreasonable IMHO.

Thanks for the clarification.

-- Gaby

[Joseph S. Myers]

Post by Kaveh R. Ghazi
Perhaps automake can help? Does anyone think adding automake
conversion of the gcc dir and ansi2knr as two new beginner projects is
worthwhile?

ansi2knr is not a sensible road. The benefits of using ISO C go beyond
the trivial syntax changes in function declarations and definitions and
keeping things limited so a converter can work is a bad idea.

I believe at least some of the people who've done most of the work on the
build system lately also dislike automake. We shouldn't go adding things
to the projects list that are far from being agreed as a good idea.
There's enough there already that has either been done, or is obsolete, or
no longer seems generally such a good idea as it did to someone when the
entries were put on the lists.

[Gabriel Dos Reis]

"Joseph S. Myers" <***@cam.ac.uk> writes:

| On Thu, 9 Jan 2003, Kaveh R. Ghazi wrote:
|
| > Perhaps automake can help? Does anyone think adding automake
| > conversion of the gcc dir and ansi2knr as two new beginner projects is
| > worthwhile?
|
| ansi2knr is not a sensible road. The benefits of using ISO C go beyond
| the trivial syntax changes in function declarations and definitions and
| keeping things limited so a converter can work is a bad idea.

Yeah, my "conversion" went behond mere prototyping: I made some
functions use and return "bool" where appropriate.

-- Gaby

[Kaveh R. Ghazi]

Post by Gabriel Dos Reis
|
| > Perhaps automake can help? Does anyone think adding automake
| > conversion of the gcc dir and ansi2knr as two new beginner projects is
| > worthwhile?
|
| ansi2knr is not a sensible road. The benefits of using ISO C go beyond
| the trivial syntax changes in function declarations and definitions and
| keeping things limited so a converter can work is a bad idea.
Yeah, my "conversion" went behond mere prototyping: I made some
functions use and return "bool" where appropriate.
-- Gaby

Note using "bool" (i.e. char) in a prototype is a GCC extension, not
ISO C, and -pedantic will spank you for it. So "bool" should never be
allowed in the core compiler (well, not until GCC crushes all
competitors. :-)

OTOH, using "bool" as a return type is fine everywhere, even right now.

--Kaveh

PS: I agree that ansi2knr isn't good for the reasons already stated.

--
Kaveh R. Ghazi ***@caip.rutgers.edu

[Gabriel Dos Reis]

"Kaveh R. Ghazi" <***@caip.rutgers.edu> writes:

| > From: Gabriel Dos Reis <***@integrable-solutions.net>
| >
| > "Joseph S. Myers" <***@cam.ac.uk> writes:
| >
| > | On Thu, 9 Jan 2003, Kaveh R. Ghazi wrote:
| > |
| > | > Perhaps automake can help? Does anyone think adding automake
| > | > conversion of the gcc dir and ansi2knr as two new beginner projects is
| > | > worthwhile?
| > |
| > | ansi2knr is not a sensible road. The benefits of using ISO C go beyond
| > | the trivial syntax changes in function declarations and definitions and
| > | keeping things limited so a converter can work is a bad idea.
| >
| > Yeah, my "conversion" went behond mere prototyping: I made some
| > functions use and return "bool" where appropriate.
| > -- Gaby
|
| Note using "bool" (i.e. char) in a prototype is a GCC extension,

Yes, I'm well aware of that. We started using bool long before we
started ansifying function prototypes.

| not
| ISO C, and -pedantic will spank you for it. So "bool" should never be
| allowed in the core compiler (well, not until GCC crushes all
| competitors. :-)

It depends on what you call "core compiler". For example, it is safe
if prototypes are seen before actual use -- which is the case in the
other front-ends.

It is an error in K&R mode.

-- Gaby

[Kaveh R. Ghazi]

| not ISO C, and -pedantic will spank you for it. So "bool" should never be
| allowed in the core compiler (well, not until GCC crushes all
| competitors. :-)
It depends on what you call "core compiler". For example, it is safe
if prototypes are seen before actual use -- which is the case in the
other front-ends.

Yes, "safe" if the compiler allows it, ISO C does not.

By "core compiler" I meant the parts of GCC that a stage1 compiler
would be expected to build, which today are written in K&R but in the
future I would expect they would be in strict ISO C style so that
vendor compilers would continue to be able to build stage1.

Another way of looking at it is when we eliminate K&R support we would
remove -Wtraditional, but keep -pedantic in the stage1 parts. These
are the places where you can't use "bool" as a parameter.

It is an error in K&R mode.

Actually, since prototypes are elided by PARAMS and get promoted to
"int" in function definitions, you *can* use bool in K&R mode (as long
as system.h defines bool to char e.g.) It's ISO C where we have
problems. :-)

--
Kaveh R. Ghazi ***@caip.rutgers.edu

[Kaveh R. Ghazi]

Post by Kaveh R. Ghazi

Post by Gabriel Dos Reis
It depends on what you call "core compiler". For example, it is safe
if prototypes are seen before actual use -- which is the case in the
other front-ends.

Yes, "safe" if the compiler allows it, ISO C does not.

Sorry I goofed, let me clarify.

This is allowed in ISO C (assuming bool is char if necessary.)

Post by Kaveh R. Ghazi
extern void foo (bool);
void foo (bool a)
{
}
extern void bar (bool);
void bar (a)
bool a;
{
}

GCC accepts the latter as an extension.


When we finally convert the "core compiler" function definitions to
ISO style, as in the first example, then "bool" should work as
parameters there too.

--Kaveh
--
Kaveh R. Ghazi ***@caip.rutgers.edu

[Bruce Korb]

Post by Nathanael Nerode
First of all, we clearly *are* going to reexamine it. It only exists
because HP still ships a K&R compiler by default with HPUX; this has to
end or become irrelevant sometime.

Is there a problem with forcing people who don't have the HP /opt/ansic
compiler to either use a prebuilt or bootstrap with an older GCC?
I am forever curious why it is important to self-hobble development
when the 0.01% of GCC clients with this problem have workarounds.

[Daniel Berlin]

Post by Bruce Korb

Post by Nathanael Nerode
First of all, we clearly *are* going to reexamine it. It only exists
because HP still ships a K&R compiler by default with HPUX; this has to
end or become irrelevant sometime.

Is there a problem with forcing people who don't have the HP /opt/ansic
compiler to either use a prebuilt or bootstrap with an older GCC?
I am forever curious why it is important to self-hobble development
when the 0.01% of GCC clients with this problem have workarounds.

I have to admit, i don't understand this either.
We've made yet another release they can use to start from.
Are there really no binaries of the past 80000 versions of gcc they can
use to bootstrap with, for those that even care about bootstrapping?
Aren't most of these HP users generally not individuals anyway,
instead, having some admin install something on a HP box that they all
use?
I don't know anyone who has individual HP/UX boxes, but maybe it's just
me.
If so, this would mean that probably only 0.01% of those 0.01% have to
worry about getting binaries *anyway*, assuming they don't have
/opt/ansic.

At some point, the number of people this affects gets so small that
it's easier to keep a list of all of them, and set up a site for them
to get binaries as a courtesy when we do releases.
:)
I'm sure all 6 of them would appreciate it.
:) :)
--Dan

[Tom Tromey]

[ HP ships non-ansi compiler ]
Dan> We've made yet another release they can use to start from.
Dan> Are there really no binaries of the past 80000 versions of gcc they
Dan> can use to bootstrap with, for those that even care about
Dan> bootstrapping?

Back in the day, Sun stopped shipping any compiler at all with their
OS. gcc users had to bootstrap by getting a precompiled gcc, and then
using that to build a newer gcc.

So, I don't think this is a big problem. With volunteer help, we
could even put precompiled HP executables of some fixed version of gcc
on the ftp site.

Tom

[Stan Shebs]

Post by Tom Tromey
[ HP ships non-ansi compiler ]
Dan> We've made yet another release they can use to start from.
Dan> Are there really no binaries of the past 80000 versions of gcc they
Dan> can use to bootstrap with, for those that even care about
Dan> bootstrapping?
Back in the day, Sun stopped shipping any compiler at all with their
OS. gcc users had to bootstrap by getting a precompiled gcc, and then
using that to build a newer gcc.
So, I don't think this is a big problem. With volunteer help, we
could even put precompiled HP executables of some fixed version of gcc
on the ftp site.

Since Jeff seems not to be around, I'll fill in for him. :-) The killer
problem that I recall him describing is that in the past there have been
HPUX releases where the precompiled executables for the previous release
would not work correctly, thus breaking the chain of GCC bootstrapping
itself, and you'd have to start over with a native compiler, but the
only ubiquitous compiler on HPs is K&R. To make it worse, there is not
a complete toolchain port to HPUX, so cross-compiling is not an option.

Yes, this is an unfortunate situation all around, which is why we
want to review it periodically, as in asking "why are we doing this
to ourselves for the sake of a proprietary OS that routinely breaks
compatibility?" :-)

Stan

[Tom Tromey]

Post by Tom Tromey
So, I don't think this is a big problem. With volunteer help, we
could even put precompiled HP executables of some fixed version of gcc
on the ftp site.

Stan> The killer problem that I recall him describing is that in the
Stan> past there have been HPUX releases where the precompiled
Stan> executables for the previous release would not work correctly,
Stan> thus breaking the chain of GCC bootstrapping itself, and you'd
Stan> have to start over with a native compiler, but the only
Stan> ubiquitous compiler on HPs is K&R.

That is a problem. However, it seems that there must be at least one
member of the gcc community with access to HP's ANSI compiler. That
person or persons could help out by compiling gcc when necessary.
Perhaps HP could even help by appointing someone to do this in-house.
(One suspects that isn't likely to happen though.)

I see moving to ANSI source as being fairly beneficial to everybody.
It will increase the maintainability of gcc. From my perspective, HP
is not an important enough platform to warrant this amount of effort
on everybody's part. Rather, I'd prefer it if the effort were
centered more on those who actively care about the port.

Tom

[Daniel Berlin]

[This is way too long of a response, but it's late, and i'm tired, and
i'm going to try to make every conceivable argument why we should stop
doing this, and then just be silent forever. :P]

Post by Tom Tromey
Stan> The killer problem that I recall him describing is that in the
Stan> past there have been HPUX releases where the precompiled
Stan> executables for the previous release would not work correctly,
Stan> thus breaking the chain of GCC bootstrapping itself, and you'd
Stan> have to start over with a native compiler, but the only
Stan> ubiquitous compiler on HPs is K&R.
That is a problem. However, it seems that there must be at least one
member of the gcc community with access to HP's ANSI compiler. That
person or persons could help out by compiling gcc when necessary.
Perhaps HP could even help by appointing someone to do this in-house.
(One suspects that isn't likely to happen though.)
I see moving to ANSI source as being fairly beneficial to everybody.
It will increase the maintainability of gcc. From my perspective, HP
is not an important enough platform to warrant this amount of effort
on everybody's part. Rather, I'd prefer it if the effort were
centered more on those who actively care about the port.

I agree completely.
Especially given that HP doesn't appear like they will ever ship an
ANSI C compiler for free. According to an email a google search found
from Jeff, HPUX 9, 10, and 11 only come with a K&R compiler. HPUX 8 was
"too long ago" to remember what it came with. So why should we help
*them* out, at *our* expense, when it's not a temporary situation, and
has been going on for years?

My google searches show that every time someone asks about not being
able to compile pieces of code that are ANSI (not just gcc, other
packages as well), the answer is "get gcc from <pick one of the
apparently common hpux binaries sites>, or spend about a thousand bucks
on HP's compiler".

It's even in FAQs:
"
Subject: 8.3 How come the default C compiler is brain-dead?

The C compiler shipped with HP-UX is intended only to rebuild the kernel
with, not for program development. To get a "real" C compiler, you must
buy the ANSI C program development bundle."

So it doesn't appear like gcc is the *only* piece of code people can't
compile on HPUX without an ANSI compiler, and people seem to know this.

This would lead me to believe that people who *do* want to compile
code, probably have working ANSI compilers by the time they want to
start bootstrapping gcc, unless that's all they've ever wanted to
compile.

I just don't see where it's *such* a big deal that HPUX users have to
have an ANSI c compiler to bootstrap gcc.

The funny part is that HP agrees.
It appears their official line is that the C compiler shipped with
HP-UX is only intended to rebuild the kernel, *not* for program
development.

So tell me again why we think it's a good idea to require everyone
developing gcc to not use ANSI C in the core so that we can use a
compiler not intended for program development, for program development?

Everyone else seems to FAQ it and be done with it (i'm googling on
"ansi compiler hpux").
PostgreSQL:
"1.1) What do I need to install PostgreSQL on HP-UX?
...
Aside from the PostgreSQL source distribution, you will need GNU make
(HP's make will not do), and either GNU gcc or HP's full ANSI C
compiler. If you intend to build from CVS sources rather than a
distribution tarball, you will also need flex (GNU lex) and bison (GNU
yacc). "
SAMBA:
"Chapter 24. Portability

Samba works on a wide range of platforms but the interface all the
platforms provide is not always compatible. This chapter contains
platform-specific information about compiling and using samba.

24.1. HPUX
...
On HPUX you must use gcc or the HP Ansi compiler. The free compiler
that comes with HP-UX is not Ansi compliant and cannot compile Samba.

24.2. SCO Unix
"

The only widely used project i can find besides gcc that does K&R
specifically is lynx.
Even they seem to want to see if they can give up, because one of the
libraries they depend on gave up a long time ago; From the lynx
todo-list:

"Lynx currently uses a greatly altered copy of libwww v2.14, which is
somewhat elderly. Lynx should be upgraded to use the current libwww
v5.0, and the bugfixes and enhancements from Lynx's copy of 2.14 should
be provided for 5.0. This upgrade would give Lynx HTTP/1.1 capability,
and would make more elaborate table support possible. (wwwlib 5 seems
to be written in ANSI C, with no concessions to K&R. If that's correct,
then we can convert the Lynx source code to ANSI as well---would any
platforms lose by this?) "

Given *all* of this, i just don't see why we require effort on the part
of *everyone* , when the situation is *not* going to change. What is
to be gained by, for example, waiting 2 years to convert. The exact
same set of problems will exist then that we have now, and we'll have
the exact same discussion. "Deprecating" K&R now and removing it later
doesn't help anyone or actually change the situation, since HPUX users
either have an ANSI compiler, and thus, it's not an issue for them, or
they can't compile any other piece of software anyway (besides lynx,
which uses curses libraries that need ansi compilers. :P) without
getting gcc binaries, bootstrapping gcc, or buying HP's ANSI compiler.
The affected people will be those who would have bootstrapped gcc, and
don't know how to get binaries now, which seems to me it would be an
empty set (they are smart enough to download the source to, configure,
and install gcc from source, but are stymied by having to download and
install binaries of it. hmmmm).

It also won't matter for the average user because the likely reality is
that the following sequence occurs:

1. They download source to anything on earth other than gcc and lynx.
2. They attempt to configure, compile, and install.
3. They get an error, and write the mailing list for the program they
wanted to compile.
4a. Half the time, the response is to get *binaries* of gcc from a
certain site or buy hp's ansi c compiler. They do this, and are happy.
End scenario.
4b. Half the time, the response is to get gcc or buy hp's ansi c
compiler.
5. They go looking for gcc.
6. They download the source, because nothing in directions for getting
gcc points them elsewhere.
7. They spend a few hours compiling and installing gcc.

Our solution is currently:
Make gcc compilable by those users who get to step 6

Rather than:
Make sure if they go looking for gcc on the gcc site, they see a
message saying, basically "If you are an HP/UX user who simply wants to
compile *other* software with gcc, you can get by with binary
distributions. These are available at x, y, z. We have no preference
for which you choose, and are only trying to save you the trouble of
downloading and compiling gcc just so you can get a compiler that
supports ansi c."

Okay, I think i'm all K&R'd out, and got it all off my chest.
I guess one doesn't realize how much angst PARAMS and weird function
argument syntax can cause until you sit down and start writing about
getting rid of them. :P

--Dan

Post by Tom Tromey
Tom

[Zack Weinberg]

Current discussion focusses on using C89 syntax without
conditionalization. I'd like to redirect things a bit. An entirely
serious question: Are we prepared to drop support for hosts and hosted
targets which do not provide a C89 compliant standard library? This
would, for instance, permit the total removal of fix-header (not to be
confused with fixincludes); considerable trimming down of system.h and
configure.in; the removal of quite a bit of libiberty; and so on.

I don't personally see that much of an advantage to C89 syntax, but
being able to make more assumptions about the library baseline would
be a big improvement IMO.

It's my belief that most of these hosts and targets were nailed by the
deprecation list I posted for 3.3 a few weeks back, but I am not 100%
sure. And I got pushback on a few of them, notably SunOS 4.

zw

[Joseph S. Myers]

Post by Zack Weinberg
Current discussion focusses on using C89 syntax without
conditionalization. I'd like to redirect things a bit. An entirely
serious question: Are we prepared to drop support for hosts and hosted
targets which do not provide a C89 compliant standard library? This
would, for instance, permit the total removal of fix-header (not to be
confused with fixincludes); considerable trimming down of system.h and
configure.in; the removal of quite a bit of libiberty; and so on.

Changes to libiberty require tie-in from other projects. Has binutils
abandoned K&R syntax, or would it follow GCC in this? Would binutils and
GDB follow GCC in the removal of support for old libraries?

Post by Zack Weinberg
I don't personally see that much of an advantage to C89 syntax, but
being able to make more assumptions about the library baseline would
be a big improvement IMO.

Whereas I think that using standard syntax allows lots of cleanups such as
using string concatenation, whereas most library variations are
effectively covered and encapsulated by libiberty etc..

[Richard Earnshaw]

Post by Joseph S. Myers
Changes to libiberty require tie-in from other projects. Has binutils
abandoned K&R syntax, or would it follow GCC in this? Would binutils and
GDB follow GCC in the removal of support for old libraries?

GDB has already switched to ANSI/ISO C. Binutils is waiting for GCC, on
the grounds that GCC is the more complex project. But it's a continual
struggle to prevent ANSIisms creeping in, since almost nobody is is
testing with K+R compilers these days.

R.

[Jim Wilson]

Has binutils abandoned K&R syntax, or would it follow GCC in this?

There is a general consensus among binutils developers that switching from
K&R to C89 is a good idea. However, since binutils is required by some
targets for bootstrapping gcc, and gcc has the policy that bootstraps should
be possible with K&R compilers, a binutils switch would break gcc. Therefore,
they are waiting for gcc to switch first.

Jim

[Stan Shebs]

Post by Jim Wilson

Has binutils abandoned K&R syntax, or would it follow GCC in this?

There is a general consensus among binutils developers that switching from
K&R to C89 is a good idea. However, since binutils is required by some
targets for bootstrapping gcc, and gcc has the policy that bootstraps should
be possible with K&R compilers, a binutils switch would break gcc. Therefore,
they are waiting for gcc to switch first.

I believe the consensus from last year was for the SC to review the K&R
requirement periodically. With 3.3 branched and 3.4 hacking proceeding
apace, this seems like a good a time as any to see if K&R compatibility
still looks as valuable as it did before.

Stan

[Jim Wilson]

This question of K&R support has traditionally been a question of whether we
supported both K&R and C89 or only C89. However, we really have 3 languages
here, K&R, C89, and C99. Supporting 3 languages is much harder than supporting
just two.

I think the policy here should be that we support only the last two major
revisions to the C language. That would mean only C89 and C99 for now.
And in 6 years, when C09 comes out, we drop support for C89. We could perhaps
add a couple of years of slack to allow for adoption of new language standards,
but that is just a minor detail.

Jim

[Nathanael Nerode]

Post by Gabriel Dos Reis
Yeah, my "conversion" went behond mere prototyping: I made some
functions use and return "bool" where appropriate.
-- Gaby

My point is that parser.c is already full of 'bool', as will as
ANSI-style function definitions and declarations.

I see no loss in my patch, and some potential gain.

If Zack really cares, I invite him to submit a patch removing *all*
ANSIisms from parser.c so my patch can compete with something real,
rather than the ghost of a possible future.

--Nathanael

[Zack Weinberg]

Post by Nathanael Nerode

Post by Gabriel Dos Reis
Yeah, my "conversion" went behond mere prototyping: I made some
functions use and return "bool" where appropriate.
-- Gaby

My point is that parser.c is already full of 'bool', as will as
ANSI-style function definitions and declarations.
I see no loss in my patch, and some potential gain.

I didn't realize that. In that case I withdraw the objection.

zw