* 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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.