Am 20.05.19 um 19:04 schrieb marcandre.lur...@redhat.com:
> From: Marc-André Lureau <mlur...@redhat.com>
>
> This adds xfuncname and word_regex patterns for Rust, a quite
> popular programming language. It also includes test cases for the
> xfuncname regex (t4018) and updated documentation.
>
> The word_regex pattern finds identifiers, integers, floats and
> operators, according to the Rust Reference Book.
This looks very good. I have a few questions regarding the hunk header
regex.
> diff --git a/userdiff.c b/userdiff.c
> index 3a78fbf504..e45b5920c6 100644
> --- a/userdiff.c
> +++ b/userdiff.c
> @@ -130,6 +130,12 @@ PATTERNS("ruby", "^[ \t]*((class|module|def)[ \t].*)$",
> "(@|@@|\\$)?[a-zA-Z_][a-zA-Z0-9_]*"
> "|[-+0-9.e]+|0[xXbB]?[0-9a-fA-F]+|\\?(\\\\C-)?(\\\\M-)?."
> "|//=?|[-+*/<>%&^|=!]=|<<=?|>>=?|===|\\.{1,3}|::|[!=]~"),
> +PATTERNS("rust",
> + "^[\t ]*((pub(\\([^\\)]+\\))?[\t ]+)?((async|const|unsafe|extern([\t
> ]+\"[^\"]+\"))[\t ]+)?(struct|enum|union|mod|trait|fn|impl(<.+>)?)[
> \t]+[^;]*)$",
This pattern matches only if there is no semicolon behind the signal
words on the line. Is that important? Can you show a (test) case where a
line with a semicolon would be picked incorrectly if '[^;]*' were
simplified to '.*'?
You permit whitespace at the beginning of an anchor line. I guess that
is to catch nested definitions. Or is it common style to write indented
code? Can you show a test case where this makes sense?
Would it be sufficient to simplify
(struct|enum|union|mod|trait|fn|impl(<.+>)?)[ \t]+
to
(struct|enum|union|mod|trait|fn|impl)[< \t]+
as it is only important to exclude identifiers that start with these
keywords.
> + /* -- */
> + "[a-zA-Z_][a-zA-Z0-9_]*"
> + "|[0-9][0-9_a-fA-Fiosuxz]*(\\.([0-9]*[eE][+-]?)?[0-9_fF]*)?"
> + "|[-+*\\/<>%&^|=!:]=|<<=?|>>=?|&&|\\|\\||->|=>|\\.{2}=|\\.{3}|::"),
> PATTERNS("bibtex", "(@[a-zA-Z]{1,}[ \t]*\\{{0,1}[ \t]*[^
> \t\"@',\\#}{~%]*).*$",
> "[={}\"]|[^={}\" \t]+"),
> PATTERNS("tex", "^(\\\\((sub)*section|chapter|part)\\*{0,1}\\{.*)$",
>
> base-commit: aa25c82427ae70aebf3b8f970f2afd54e9a2a8c6
-- Hannes
