public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jeff Law <law@redhat.com>
To: David Malcolm <dmalcolm@redhat.com>, gcc-patches@gcc.gnu.org
Cc: Trevor Saunders <tbsaunde@tbsaunde.org>
Subject: Re: [PATCH 2/3] Matching tokens: C parts (v2)
Date: Fri, 04 Aug 2017 18:09:00 -0000	[thread overview]
Message-ID: <54e35f0f-e5cd-1e39-efb5-a1791b29b598@redhat.com> (raw)
In-Reply-To: <1501857163.4181.23.camel@redhat.com>

On 08/04/2017 08:32 AM, David Malcolm wrote:
> On Thu, 2017-08-03 at 11:34 -0600, Jeff Law wrote:
>> On 08/01/2017 02:21 PM, David Malcolm wrote:
>>> Changed in v2:
>>>
>>> * Renamed template argument to traits_t; eliminated subclasses,
>>> just
>>>   using traits struct.
>>> * Moved enum constants into struct bodies (string constants can't
>>> be
>>>   without constexpr, which isn't available in C++98).
>>> * Fixed typo.
>>>
>>> OK for trunk?
>>>
>>> gcc/c/ChangeLog:
>>> 	* c-parser.c (c_parser_error): Rename to...
>>> 	(c_parser_error_richloc): ...this, making static, and adding
>>> 	"richloc" parameter, passing it to the c_parse_error call,
>>> 	rather than calling c_parser_set_source_position_from_token.
>>> 	(c_parser_error): Reintroduce, reimplementing in terms of the
>>> 	above, converting return type from void to bool.
>>> 	(class token_pair): New class.
>>> 	(struct matching_paren_traits): New struct.
>>> 	(matching_parens): New typedef.
>>> 	(struct matching_brace_traits): New struct.
>>> 	(matching_braces): New typedef.
>>> 	(get_matching_symbol): New function.
>>> 	(c_parser_require): Add param MATCHING_LOCATION, using it to
>>> 	highlight matching "opening" tokens for missing "closing"
>>> tokens.
>>> 	(c_parser_skip_until_found): Likewise.
>>> 	(c_parser_static_assert_declaration_no_semi): Convert explicit
>>> 	parsing of CPP_OPEN_PAREN and CPP_CLOSE_PAREN to use of
>>> 	class matching_parens, so that the pertinent open parenthesis
>>> is
>>> 	highlighted when there are problems locating the close
>>> 	parenthesis.
>>> 	(c_parser_struct_or_union_specifier): Likewise.
>>> 	(c_parser_typeof_specifier): Likewise.
>>> 	(c_parser_alignas_specifier): Likewise.
>>> 	(c_parser_simple_asm_expr): Likewise.
>>> 	(c_parser_braced_init): Likewise, for matching_braces.
>>> 	(c_parser_paren_condition): Likewise, for matching_parens.
>>> 	(c_parser_switch_statement): Likewise.
>>> 	(c_parser_for_statement): Likewise.
>>> 	(c_parser_asm_statement): Likewise.
>>> 	(c_parser_asm_operands): Likewise.
>>> 	(c_parser_cast_expression): Likewise.
>>> 	(c_parser_sizeof_expression): Likewise.
>>> 	(c_parser_alignof_expression): Likewise.
>>> 	(c_parser_generic_selection): Likewise.
>>> 	(c_parser_postfix_expression): Likewise for cases RID_VA_ARG,
>>> 	RID_OFFSETOF, RID_TYPES_COMPATIBLE_P, RID_AT_SELECTOR,
>>> 	RID_AT_PROTOCOL, RID_AT_ENCODE, reindenting as necessary.
>>> 	In case CPP_OPEN_PAREN, pass loc_open_paren to the
>>> 	c_parser_skip_until_found call.
>>> 	(c_parser_objc_class_definition): Use class matching_parens as
>>> 	above.
>>> 	(c_parser_objc_method_decl): Likewise.
>>> 	(c_parser_objc_try_catch_finally_statement): Likewise.
>>> 	(c_parser_objc_synchronized_statement): Likewise.
>>> 	(c_parser_objc_at_property_declaration): Likewise.
>>> 	(c_parser_oacc_wait_list): Likewise.
>>> 	(c_parser_omp_var_list_parens): Likewise.
>>> 	(c_parser_omp_clause_collapse): Likewise.
>>> 	(c_parser_omp_clause_default): Likewise.
>>> 	(c_parser_omp_clause_if): Likewise.
>>> 	(c_parser_omp_clause_num_threads): Likewise.
>>> 	(c_parser_omp_clause_num_tasks): Likewise.
>>> 	(c_parser_omp_clause_grainsize): Likewise.
>>> 	(c_parser_omp_clause_priority): Likewise.
>>> 	(c_parser_omp_clause_hint): Likewise.
>>> 	(c_parser_omp_clause_defaultmap): Likewise.
>>> 	(c_parser_oacc_single_int_clause): Likewise.
>>> 	(c_parser_omp_clause_ordered): Likewise.
>>> 	(c_parser_omp_clause_reduction): Likewise.
>>> 	(c_parser_omp_clause_schedule): Likewise.
>>> 	(c_parser_omp_clause_num_teams): Likewise.
>>> 	(c_parser_omp_clause_thread_limit): Likewise.
>>> 	(c_parser_omp_clause_aligned): Likewise.
>>> 	(c_parser_omp_clause_linear): Likewise.
>>> 	(c_parser_omp_clause_safelen): Likewise.
>>> 	(c_parser_omp_clause_simdlen): Likewise.
>>> 	(c_parser_omp_clause_depend): Likewise.
>>> 	(c_parser_omp_clause_map): Likewise.
>>> 	(c_parser_omp_clause_device): Likewise.
>>> 	(c_parser_omp_clause_dist_schedule): Likewise.
>>> 	(c_parser_omp_clause_proc_bind): Likewise.
>>> 	(c_parser_omp_clause_uniform): Likewise.
>>> 	(c_parser_omp_for_loop): Likewise.
>>> 	(c_parser_cilk_clause_vectorlength): Likewise.
>>> 	(c_parser_cilk_clause_linear): Likewise.
>>> 	(c_parser_transaction_expression): Likewise.
>>> 	* c-parser.h (c_parser_require): Add param matching_location
>>> with
>>> 	default UNKNOWN_LOCATION.
>>> 	(c_parser_error): Convert return type from void to bool.
>>> 	(c_parser_skip_until_found): Add param matching_location with
>>> 	default UNKNOWN_LOCATION.
>>>
>>> gcc/testsuite/ChangeLog:
>>> 	* gcc.dg/unclosed-init.c: New test case.
>>
>> Phew.  I only spot-checked most of the changes around the new API for
>> requiring the open/close paren/brace/bracket or consuming
>> parens/braces/brackets.  They were very mechanical :-)
> 
> Thanks for looking at this.  Do you have an opinion on Trevor's idea
> the the "parser" argument should be moved into the token_pair class (to
> avoid manually passing it in everywhere), or should it be kept outside
> and passed in as needed? 
No opinion.  I'd put it where ever it makes the  most logical sense in
terms of code readability -- until such a point as it's shown to be a
bottleneck.

> 
> I was worried about increasing register pressure in the parsers, since
> it's not clear to me that the optimizer can always prove that a field
> "token_pair::m_parser" in a local token_pair is equal to the parser
> local (see:
> https://gcc.gnu.org/ml/gcc-patches/2017-08/msg00114.html )
The ability to prove they're the same would depend on aliasing
relationships and whether or not the objects escape as well. Odds are it
won't be able to determine that in general.

jeff

  reply	other threads:[~2017-08-04 18:09 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-11 14:51 [PATCH 0/3] C/C++: show pertinent open token when missing a close token David Malcolm
2017-07-11 14:51 ` [PATCH 1/3] matching tokens: c-family parts David Malcolm
2017-07-18 17:23   ` Marek Polacek
2017-07-11 14:51 ` [PATCH 2/3] matching tokens: C parts David Malcolm
2017-07-11 14:51 ` [PATCH 3/3] matching tokens: C++ parts David Malcolm
2017-07-12 13:13   ` Trevor Saunders
2017-07-12 15:12     ` Martin Sebor
2017-07-16 17:55       ` Trevor Saunders
2017-08-01 19:47     ` [PATCH 0/3 v2] C/C++: show pertinent open token when missing a close token David Malcolm
2017-08-01 19:47       ` [PATCH 3/3] matching tokens: C++ parts (v2) David Malcolm
2017-08-07 18:25         ` Jason Merrill
2017-08-08 20:26           ` [PATCH] matching tokens: C++ parts (v3) David Malcolm
2017-08-08 20:49             ` [PATCH] Changes for v3 of the C++ patch David Malcolm
2017-08-09 19:26             ` [PATCH] matching tokens: C++ parts (v3) Jason Merrill
2017-08-01 19:47       ` [PATCH 2/3] Matching tokens: C parts (v2) David Malcolm
2017-08-03 17:34         ` Jeff Law
2017-08-04 14:32           ` David Malcolm
2017-08-04 18:09             ` Jeff Law [this message]
2017-08-08 20:37               ` David Malcolm
2017-08-09  6:50                 ` Marek Polacek
2017-08-01 19:47       ` [PATCH 1/3] matching tokens: c-family parts David Malcolm
2017-08-03 17:22         ` Jeff Law
2017-08-02  3:03       ` [PATCH 0/3 v2] C/C++: show pertinent open token when missing a close token Trevor Saunders
2017-08-10 13:39       ` [committed, v3] " David Malcolm
2017-07-11 17:28 ` [PATCH 0/3] " Martin Sebor
2017-07-11 18:32   ` David Malcolm
2017-07-11 19:30     ` Martin Sebor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54e35f0f-e5cd-1e39-efb5-a1791b29b598@redhat.com \
    --to=law@redhat.com \
    --cc=dmalcolm@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=tbsaunde@tbsaunde.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).