From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Yuan Fu Newsgroups: gmane.emacs.bugs Subject: bug#63390: 29.0.90; c-ts-mode fails to recognize functions in xterm.c Date: Sun, 14 May 2023 22:47:06 -0700 Message-ID: References: <837cthbtkz.fsf@gnu.org> <83ttwh3iuh.fsf@gnu.org> Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.500.231\)) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17168"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 63390@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon May 15 07:48:39 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pyR4Y-0004Cq-Fp for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 15 May 2023 07:48:38 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pyR4D-0003tn-01; Mon, 15 May 2023 01:48:17 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pyR45-0003rS-9Y for bug-gnu-emacs@gnu.org; Mon, 15 May 2023 01:48:13 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pyR3y-0002lP-Mc for bug-gnu-emacs@gnu.org; Mon, 15 May 2023 01:48:08 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pyR3y-0008Qo-Hq for bug-gnu-emacs@gnu.org; Mon, 15 May 2023 01:48:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Yuan Fu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 15 May 2023 05:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63390 X-GNU-PR-Package: emacs Original-Received: via spool by 63390-submit@debbugs.gnu.org id=B63390.168412964632217 (code B ref 63390); Mon, 15 May 2023 05:48:02 +0000 Original-Received: (at 63390) by debbugs.gnu.org; 15 May 2023 05:47:26 +0000 Original-Received: from localhost ([127.0.0.1]:42476 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pyR3O-0008NZ-5g for submit@debbugs.gnu.org; Mon, 15 May 2023 01:47:26 -0400 Original-Received: from mail-pl1-f172.google.com ([209.85.214.172]:51569) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pyR3M-0008NL-6n for 63390@debbugs.gnu.org; Mon, 15 May 2023 01:47:24 -0400 Original-Received: by mail-pl1-f172.google.com with SMTP id d9443c01a7336-1aad5245632so87259515ad.3 for <63390@debbugs.gnu.org>; Sun, 14 May 2023 22:47:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684129638; x=1686721638; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=benNk5lOZUmxAkeFzCsLU7b6f9E1r4QkXjBXo603RCI=; b=bplGaL512UEURC5YXZLYHcvU7NK69dNIawBleXvQdZrfuCxe/b56eDEBJMeGAcoZC5 dbCLbgrHXMlgClAwWVRmUfr9gwe94yf6YODcHGFSb/ND9WFafVvNIdGGcFvmL/fkLhxz j4vUTDpDJdGPOZuaU4UPegtBhZv6BUvJ8mYIkauW8C70ziS0xDNV14Rx24aHjQWCk6K+ Sgq3iAx9T5RT/ixcVgg2abj56Sz96TQzD2gWoBzBa0J57Fr+QmRCy3fEOpgcqiLufGad miB20Aw7WiLhgQ6j+SnmZTCIFVgV7R/mHuVKXnufX2SYxzH/9XnCitte30yVENygOvLM UxBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684129638; x=1686721638; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=benNk5lOZUmxAkeFzCsLU7b6f9E1r4QkXjBXo603RCI=; b=b6LvgOorIbL9QWZEADbcFdCtEuFmpZdQraioEArOAEdw4EBJIZfJQ7DVsxsIfA7f2N XD9OJHvkIgKjJekBiVHT2VTFDlZLAmnTE0CqrCH/SfLZ6whc4mPHgRsbT6Rh9j/8jqvC GY9fkCSTSWq7U8WskFcG3pzTfky7Y6c/iV41jw35KISxI1jjRABCfmc2+FNpJSFCrw80 0hp6qE2cr/ecFskO9ClY48B5CPLC0FSU9jHEEhvWQkPTR0kbWhOGPc0HdJ3mniLg4cOZ Zxxg+f+R9NdwNdAQOxh5b11J5RdhtQ6AVGApV7ia+0eWMBZYtQkZ0/1vqabgX1b2Ujz3 p9fA== X-Gm-Message-State: AC+VfDwhON0uEx5RexzDGHRW+6oCOyIFiW0Upp6BuHCN3s49LpR3KQX0 tAEmCsaOY4lICKeygsiuIP6It7JE/f8= X-Google-Smtp-Source: ACHHUZ5Zg2ozx8OZMztrtTvVrXDltIU+p+zf6FQNv8QvMb64jBcjj8+t9ExYaSSTkX1ar/5SkF6TMg== X-Received: by 2002:a17:902:e741:b0:1a6:77b8:23e0 with SMTP id p1-20020a170902e74100b001a677b823e0mr41969191plf.60.1684129637934; Sun, 14 May 2023 22:47:17 -0700 (PDT) Original-Received: from smtpclient.apple (cpe-172-117-161-177.socal.res.rr.com. [172.117.161.177]) by smtp.gmail.com with ESMTPSA id h6-20020a170902b94600b001ac78ac2cafsm12423161pls.239.2023.05.14.22.47.17 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 14 May 2023 22:47:17 -0700 (PDT) In-Reply-To: <83ttwh3iuh.fsf@gnu.org> X-Mailer: Apple Mail (2.3731.500.231) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:261729 Archived-At: > On May 12, 2023, at 4:11 AM, Eli Zaretskii wrote: >=20 > Yuan, could you please look into this? >=20 >> Date: Tue, 09 May 2023 15:03:08 +0300 >> From: Eli Zaretskii >>=20 >> To reproduce: >>=20 >> emacs -Q >> M-x load-library RET c-ts-mode RET >> C-x C-f src/xterm.c >> C-u 8290 M-g g >>=20 >> Observe that the name of the function x_draw_glyph_string_foreground >> is not fontified in font-lock-function-name-face, but in the default >> face. >>=20 >> Starting treesit-explore-mode seems to indicate that tree-sitter >> interprets this as a function declaration, not a function definition: >>=20 >> (function_declarator declarator: (identifier) >> parameters:=20 >> (parameter_list ( >> (parameter_declaration >> type: (struct_specifier struct name: (type_identifier)) >> declarator: (pointer_declarator * declarator: (identifier))) >> ))) >>=20 >> Same with the next function, = x_draw_composite_glyph_string_foreground. >> But the function after that, = x_draw_glyphless_glyph_string_foreground, >> is again recognized as function definition. I wonder if the >> preprocessor conditionals around there have something to do with = that. Ok, so that=E2=80=99s because there are ifdef=E2=80=99s inside the = function, which cuts the function into pieces and tree-sitter can=E2=80=99= t make out a function_definition, which is what we use to fontify the = function name. A function_declarator alone can be used in many places, = like in an argument list for function pointers, I think? I can fix this by fontifying top-level function_declaration, I think a = top-level function_declaration should always be a function definition? >>=20 >> Btw, function declarations in a header file are recognized as such, >> but the names of the functions there are still correctly fontified. They are fine because there=E2=80=99s a semicolon in the end, so the = function_decalration is wrapped in a declaration node, which we (the = fontification rules) recognize. Yuan=