* bug#62339: cc-mode fontifies variables incorrectly when const follows type @ 2023-03-21 15:14 Daniel Colascione 2023-03-21 17:39 ` Eli Zaretskii 0 siblings, 1 reply; 14+ messages in thread From: Daniel Colascione @ 2023-03-21 15:14 UTC (permalink / raw) To: 62339 cc-mode incorrectly fontifies my_variable as a type in "MyType const my_variable" ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#62339: cc-mode fontifies variables incorrectly when const follows type 2023-03-21 15:14 bug#62339: cc-mode fontifies variables incorrectly when const follows type Daniel Colascione @ 2023-03-21 17:39 ` Eli Zaretskii 2023-03-22 14:19 ` Daniel Colascione 0 siblings, 1 reply; 14+ messages in thread From: Eli Zaretskii @ 2023-03-21 17:39 UTC (permalink / raw) To: Daniel Colascione; +Cc: 62339 > From: Daniel Colascione <dancol@dancol.org> > Date: Tue, 21 Mar 2023 11:14:13 -0400 > > > cc-mode incorrectly fontifies my_variable as a type in "MyType const > my_variable" I cannot reproduce this, at least not in Emacs 29 and 30. In which version of Emacs do you see this? If Emacs 29 or later, can you show a minimal example source file where it happens? Thanks. ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#62339: cc-mode fontifies variables incorrectly when const follows type 2023-03-21 17:39 ` Eli Zaretskii @ 2023-03-22 14:19 ` Daniel Colascione 2023-03-22 15:12 ` Eli Zaretskii 0 siblings, 1 reply; 14+ messages in thread From: Daniel Colascione @ 2023-03-22 14:19 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 62339 Eli Zaretskii <eliz@gnu.org> writes: >> From: Daniel Colascione <dancol@dancol.org> >> Date: Tue, 21 Mar 2023 11:14:13 -0400 >> >> >> cc-mode incorrectly fontifies my_variable as a type in "MyType const >> my_variable" > > I cannot reproduce this, at least not in Emacs 29 and 30. In which > version of Emacs do you see this? If Emacs 29 or later, can you show > a minimal example source file where it happens? > > Thanks. This problem reproduces for me on latest master with emacs -Q: ``` TEST(Foo, Bar) { NamedTemporaryDirectory const test_directory; } ``` ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#62339: cc-mode fontifies variables incorrectly when const follows type 2023-03-22 14:19 ` Daniel Colascione @ 2023-03-22 15:12 ` Eli Zaretskii 2023-03-22 22:14 ` Alan Mackenzie 0 siblings, 1 reply; 14+ messages in thread From: Eli Zaretskii @ 2023-03-22 15:12 UTC (permalink / raw) To: Daniel Colascione, Alan Mackenzie; +Cc: 62339 > From: Daniel Colascione <dancol@dancol.org> > Cc: 62339@debbugs.gnu.org > Date: Wed, 22 Mar 2023 10:19:55 -0400 > > This problem reproduces for me on latest master with emacs -Q: > > ``` > TEST(Foo, Bar) { > NamedTemporaryDirectory const test_directory; > } > ``` Thanks. What I see with Emacs built from master is that test_directory in the above example gets font-lock-type-face in c++-mode (but not in c-mode). With Emacs built from emacs-29, both modes produce correct fontification. Alan, can you please look into this? ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#62339: cc-mode fontifies variables incorrectly when const follows type 2023-03-22 15:12 ` Eli Zaretskii @ 2023-03-22 22:14 ` Alan Mackenzie 2023-03-22 22:17 ` Daniel Colascione 0 siblings, 1 reply; 14+ messages in thread From: Alan Mackenzie @ 2023-03-22 22:14 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 62339, acm, Daniel Colascione Hello, Eli and Daniel. Thanks for the bug report! On Wed, Mar 22, 2023 at 17:12:52 +0200, Eli Zaretskii wrote: > > From: Daniel Colascione <dancol@dancol.org> > > Cc: 62339@debbugs.gnu.org > > Date: Wed, 22 Mar 2023 10:19:55 -0400 > > This problem reproduces for me on latest master with emacs -Q: > > ``` > > TEST(Foo, Bar) { > > NamedTemporaryDirectory const test_directory; > > } > > ``` > Thanks. What I see with Emacs built from master is that > test_directory in the above example gets font-lock-type-face in > c++-mode (but not in c-mode). With Emacs built from emacs-29, both > modes produce correct fontification. > Alan, can you please look into this? I think this is caused by a faulty fix of bug #59267, where "typeless" C declarations like const foo; , which are implicit int, were not being recognised. In the current test case, in C Mode, NamedTemporaryDirectory ought to be getting fontified as a type, but isn't. In C++ Mode, test_directory gets spuriously fontified as a type, as already noted. Seeing as how the current bug affects only the master branch, not the emacs-29 branch, I think I'm going to take a bit of time to fix this bug in the hope of fixing it properly this time. -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#62339: cc-mode fontifies variables incorrectly when const follows type 2023-03-22 22:14 ` Alan Mackenzie @ 2023-03-22 22:17 ` Daniel Colascione 2023-03-23 0:42 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2023-03-23 14:40 ` Alan Mackenzie 0 siblings, 2 replies; 14+ messages in thread From: Daniel Colascione @ 2023-03-22 22:17 UTC (permalink / raw) To: Alan Mackenzie; +Cc: 62339, Eli Zaretskii Alan Mackenzie <acm@muc.de> writes: > Hello, Eli and Daniel. > > Thanks for the bug report! > > On Wed, Mar 22, 2023 at 17:12:52 +0200, Eli Zaretskii wrote: >> > From: Daniel Colascione <dancol@dancol.org> >> > Cc: 62339@debbugs.gnu.org >> > Date: Wed, 22 Mar 2023 10:19:55 -0400 > >> > This problem reproduces for me on latest master with emacs -Q: > >> > ``` >> > TEST(Foo, Bar) { >> > NamedTemporaryDirectory const test_directory; >> > } >> > ``` > >> Thanks. What I see with Emacs built from master is that >> test_directory in the above example gets font-lock-type-face in >> c++-mode (but not in c-mode). With Emacs built from emacs-29, both >> modes produce correct fontification. > >> Alan, can you please look into this? > > I think this is caused by a faulty fix of bug #59267, where "typeless" C > declarations like > > const foo; > > , which are implicit int, were not being recognised. Can we back out this fix in the meantime? These "typeless" declarations can't be all that common. ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#62339: cc-mode fontifies variables incorrectly when const follows type 2023-03-22 22:17 ` Daniel Colascione @ 2023-03-23 0:42 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2023-03-23 2:02 ` Daniel Colascione 2023-03-23 14:40 ` Alan Mackenzie 1 sibling, 1 reply; 14+ messages in thread From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-03-23 0:42 UTC (permalink / raw) To: Daniel Colascione; +Cc: 62339, Alan Mackenzie, Eli Zaretskii Daniel Colascione <dancol@dancol.org> writes: > Can we back out this fix in the meantime? No. > These "typeless" declarations can't be all that common. I see them more or less every day. ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#62339: cc-mode fontifies variables incorrectly when const follows type 2023-03-23 0:42 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-03-23 2:02 ` Daniel Colascione 2023-03-23 5:45 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 0 siblings, 1 reply; 14+ messages in thread From: Daniel Colascione @ 2023-03-23 2:02 UTC (permalink / raw) To: Po Lu; +Cc: 62339, Alan Mackenzie, Eli Zaretskii [-- Attachment #1: Type: text/plain, Size: 524 bytes --] On March 22, 2023 20:43:02 Po Lu <luangruo@yahoo.com> wrote: > Daniel Colascione <dancol@dancol.org> writes: > >> Can we back out this fix in the meantime? > > No. Yes, we can We lived with the old behavior for decades. We can live with it a few weeks longer. > > >> These "typeless" declarations can't be all that common. > > I see them more or less every day. Give me a break. No, you don't. Practically nobody uses this obscure and deprecated C feature. If people did, we'd have addressed the problem years ago. [-- Attachment #2: Type: text/html, Size: 1829 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#62339: cc-mode fontifies variables incorrectly when const follows type 2023-03-23 2:02 ` Daniel Colascione @ 2023-03-23 5:45 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2023-03-23 7:22 ` Eli Zaretskii 0 siblings, 1 reply; 14+ messages in thread From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-03-23 5:45 UTC (permalink / raw) To: Daniel Colascione; +Cc: 62339, Alan Mackenzie, Eli Zaretskii Daniel Colascione <dancol@dancol.org> writes: > Yes, we can We lived with the old behavior for decades. We can live with it a few weeks longer. I reported this bug because I saw such code in use. > Give me a break. No, you don't. I do. I *see* code making use of implicit int every day. > Practically nobody uses this obscure and deprecated C feature. If > people did, we'd have addressed the problem years ago. Who does ``we'' refer to? Put bluntly, you have no right to decide what C code I see or write, or what C code Alan wants to support. Declarations consisting of only a storage class specifier are part of the 1989 C Standard. This bug is no more important than bug#59267, and both will have to be fixed and stay fixed. ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#62339: cc-mode fontifies variables incorrectly when const follows type 2023-03-23 5:45 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-03-23 7:22 ` Eli Zaretskii 0 siblings, 0 replies; 14+ messages in thread From: Eli Zaretskii @ 2023-03-23 7:22 UTC (permalink / raw) To: Po Lu; +Cc: 62339, acm, dancol > From: Po Lu <luangruo@yahoo.com> > Cc: Alan Mackenzie <acm@muc.de>, <62339@debbugs.gnu.org>, Eli Zaretskii > <eliz@gnu.org> > Date: Thu, 23 Mar 2023 13:45:21 +0800 > > Daniel Colascione <dancol@dancol.org> writes: > > > Yes, we can We lived with the old behavior for decades. We can live with it a few weeks longer. > > I reported this bug because I saw such code in use. > > > Give me a break. No, you don't. > > I do. I *see* code making use of implicit int every day. > > > Practically nobody uses this obscure and deprecated C feature. If > > people did, we'd have addressed the problem years ago. > > Who does ``we'' refer to? > > Put bluntly, you have no right to decide what C code I see or write, or > what C code Alan wants to support. Declarations consisting of only a > storage class specifier are part of the 1989 C Standard. > > This bug is no more important than bug#59267, and both will have to be > fixed and stay fixed. This argument is pointless. Getting "blunt" (a.k.a. "rude") over that is certainly uncalled for. Anyone can make a local change in the relevant Lisp code if what happens in the repository doesn't suit him/her. Making a local copy of whatever cc-*.el file which causes this is very easy, and won't even cause any merge conflicts in the future, if you want to avoid it. Or make a local branch with that change and periodically merge from master. Or any other of the possible solutions. So please don't continue arguing whose use case is more important. Alan will decide whether backing out the offending "fix" is reasonable, and people who track the master branch should live with that until a better solution is found. ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#62339: cc-mode fontifies variables incorrectly when const follows type 2023-03-22 22:17 ` Daniel Colascione 2023-03-23 0:42 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-03-23 14:40 ` Alan Mackenzie 2023-04-05 15:53 ` Alan Mackenzie 1 sibling, 1 reply; 14+ messages in thread From: Alan Mackenzie @ 2023-03-23 14:40 UTC (permalink / raw) To: Daniel Colascione; +Cc: 62339, Eli Zaretskii Hello, Daniel. On Wed, Mar 22, 2023 at 18:17:05 -0400, Daniel Colascione wrote: > Alan Mackenzie <acm@muc.de> writes: > > Hello, Eli and Daniel. > > Thanks for the bug report! > > On Wed, Mar 22, 2023 at 17:12:52 +0200, Eli Zaretskii wrote: > >> > From: Daniel Colascione <dancol@dancol.org> > >> > Cc: 62339@debbugs.gnu.org > >> > Date: Wed, 22 Mar 2023 10:19:55 -0400 > >> > This problem reproduces for me on latest master with emacs -Q: > >> > ``` > >> > TEST(Foo, Bar) { > >> > NamedTemporaryDirectory const test_directory; > >> > } > >> > ``` > >> Thanks. What I see with Emacs built from master is that > >> test_directory in the above example gets font-lock-type-face in > >> c++-mode (but not in c-mode). With Emacs built from emacs-29, both > >> modes produce correct fontification. > >> Alan, can you please look into this? > > I think this is caused by a faulty fix of bug #59267, where "typeless" C > > declarations like > > const foo; > > , which are implicit int, were not being recognised. > Can we back out this fix in the meantime? These "typeless" declarations > can't be all that common. It turned out that the bug was caused by a single missing line of code, a (c-forward-syntactic-ws) in c-forward-type, so the fix wasn't too difficult. I've taken the opportunity also to fix some minor other innaccuracies in c-forward-type. Please try the following patch, and either confirm to me that it appears to fix the bug, or say what's still wrong. Thanks! diff -r 300ebf19cd62 cc-engine.el --- a/cc-engine.el Fri Feb 17 08:58:11 2023 +0000 +++ b/cc-engine.el Thu Mar 23 14:34:08 2023 +0000 @@ -9143,7 +9143,7 @@ (c-forward-syntactic-ws)) (let ((start (point)) pos res name-res id-start id-end id-range - post-prefix-pos) + post-prefix-pos prefix-end-pos) ;; Skip leading type modifiers. If any are found we know it's a ;; prefix of a type. @@ -9153,6 +9153,7 @@ (when (looking-at c-no-type-key) (setq res 'no-id))) (goto-char (match-end 1)) + (setq prefix-end-pos (point)) (setq pos (point)) (c-forward-syntactic-ws) (or (eq res 'no-id) @@ -9304,7 +9305,10 @@ (not (looking-at c-type-decl-prefix-key))))) ;; A C specifier followed by an implicit int, e.g. ;; "register count;" - (goto-char id-start) + (goto-char prefix-end-pos) + (setq pos (point)) + (unless stop-at-end + (c-forward-syntactic-ws)) (setq res 'no-id)) (name-res @@ -9312,6 +9316,7 @@ ;; A normal identifier. (goto-char id-end) (setq pos (point)) + (c-forward-syntactic-ws) (if (or res c-promote-possible-types) (progn (when (not (eq c-promote-possible-types 'just-one)) @@ -9319,7 +9324,9 @@ (when (and c-record-type-identifiers id-range) (c-record-type-id id-range)) (unless res - (setq res 'found))) + (setq res 'found)) + (when (eq res 'prefix) + (setq res t))) (setq res (if (c-check-qualified-type id-start) ;; It's an identifier that has been used as ;; a type somewhere else. -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#62339: cc-mode fontifies variables incorrectly when const follows type 2023-03-23 14:40 ` Alan Mackenzie @ 2023-04-05 15:53 ` Alan Mackenzie 2023-04-06 3:16 ` Daniel Colascione 0 siblings, 1 reply; 14+ messages in thread From: Alan Mackenzie @ 2023-04-05 15:53 UTC (permalink / raw) To: Daniel Colascione; +Cc: 62339, Eli Zaretskii Hello, Daniel. On Thu, Mar 23, 2023 at 14:40:23 +0000, Alan Mackenzie wrote: > On Wed, Mar 22, 2023 at 18:17:05 -0400, Daniel Colascione wrote: > > >> > This problem reproduces for me on latest master with emacs -Q: > > >> > ``` > > >> > TEST(Foo, Bar) { > > >> > NamedTemporaryDirectory const test_directory; > > >> > } > > >> > ``` > > >> Thanks. What I see with Emacs built from master is that > > >> test_directory in the above example gets font-lock-type-face in > > >> c++-mode (but not in c-mode). With Emacs built from emacs-29, both > > >> modes produce correct fontification. > > >> Alan, can you please look into this? [ .... ] > It turned out that the bug was caused by a single missing line of code, a > (c-forward-syntactic-ws) in c-forward-type, so the fix wasn't too > difficult. I've taken the opportunity also to fix some minor other > innaccuracies in c-forward-type. > Please try the following patch, and either confirm to me that it appears > to fix the bug, or say what's still wrong. Thanks! Ping? -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#62339: cc-mode fontifies variables incorrectly when const follows type 2023-04-05 15:53 ` Alan Mackenzie @ 2023-04-06 3:16 ` Daniel Colascione 2023-04-06 9:26 ` Alan Mackenzie 0 siblings, 1 reply; 14+ messages in thread From: Daniel Colascione @ 2023-04-06 3:16 UTC (permalink / raw) To: Alan Mackenzie; +Cc: 62339, Eli Zaretskii [-- Attachment #1: Type: text/plain, Size: 1177 bytes --] On April 5, 2023 11:53:54 Alan Mackenzie <acm@muc.de> wrote: > Hello, Daniel. > > On Thu, Mar 23, 2023 at 14:40:23 +0000, Alan Mackenzie wrote: >> On Wed, Mar 22, 2023 at 18:17:05 -0400, Daniel Colascione wrote: > >>>>>> This problem reproduces for me on latest master with emacs -Q: > >>>>>> ``` >>>>>> TEST(Foo, Bar) { >>>>>> NamedTemporaryDirectory const test_directory; >>>>>> } >>>>>> ``` > >>>>> Thanks. What I see with Emacs built from master is that >>>>> test_directory in the above example gets font-lock-type-face in >>>>> c++-mode (but not in c-mode). With Emacs built from emacs-29, both >>>>> modes produce correct fontification. > >>>>> Alan, can you please look into this? > > [ .... ] > >> It turned out that the bug was caused by a single missing line of code, a >> (c-forward-syntactic-ws) in c-forward-type, so the fix wasn't too >> difficult. I've taken the opportunity also to fix some minor other >> innaccuracies in c-forward-type. > >> Please try the following patch, and either confirm to me that it appears >> to fix the bug, or say what's still wrong. Thanks! > > Ping? Works for me. Thanks! > > -- > Alan Mackenzie (Nuremberg, Germany). [-- Attachment #2: Type: text/html, Size: 5772 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#62339: cc-mode fontifies variables incorrectly when const follows type 2023-04-06 3:16 ` Daniel Colascione @ 2023-04-06 9:26 ` Alan Mackenzie 0 siblings, 0 replies; 14+ messages in thread From: Alan Mackenzie @ 2023-04-06 9:26 UTC (permalink / raw) To: Daniel Colascione; +Cc: 62339-done, acm, Eli Zaretskii Hello, Daniel. On Wed, Apr 05, 2023 at 23:16:16 -0400, Daniel Colascione wrote: > On April 5, 2023 11:53:54 Alan Mackenzie <acm@muc.de> wrote: > > On Thu, Mar 23, 2023 at 14:40:23 +0000, Alan Mackenzie wrote: [ .... ] > >> Please try the following patch, and either confirm to me that it > >> appears to fix the bug, or say what's still wrong. Thanks! > > Ping? > Works for me. Thanks! Thanks! I've committed the patch and I'm closing the bug with this post. -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2023-04-06 9:26 UTC | newest] Thread overview: 14+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2023-03-21 15:14 bug#62339: cc-mode fontifies variables incorrectly when const follows type Daniel Colascione 2023-03-21 17:39 ` Eli Zaretskii 2023-03-22 14:19 ` Daniel Colascione 2023-03-22 15:12 ` Eli Zaretskii 2023-03-22 22:14 ` Alan Mackenzie 2023-03-22 22:17 ` Daniel Colascione 2023-03-23 0:42 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2023-03-23 2:02 ` Daniel Colascione 2023-03-23 5:45 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2023-03-23 7:22 ` Eli Zaretskii 2023-03-23 14:40 ` Alan Mackenzie 2023-04-05 15:53 ` Alan Mackenzie 2023-04-06 3:16 ` Daniel Colascione 2023-04-06 9:26 ` Alan Mackenzie
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git 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).