bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#23053: 25.0.92; error in cc-mode when editing C# file with a generic


From: Saulius Menkevičius
Subject: bug#23053: 25.0.92; error in cc-mode when editing C# file with a generic class inheritance
Date: Mon, 21 Mar 2016 23:53:22 +0200
User-agent: mu4e 0.9.16; emacs 25.0.92.5

Jostein Kjønigsen <jostein@secure.kjonigsen.net> writes:

> On Mon, Mar 21, 2016, at 01:26 PM, Alan Mackenzie wrote:
>> If so, could you possibly give me details of the
>> version of the emacs-25 branch you saw it in, and any other details I'd
>> need to reproduce it.  Thanks!
>
> I've been tracking Emacs git master. Currently I'm at this point:
>
>> commit 58862751bde2611d9ea99a33ecb5b0c13a7513b9
>> Author: Glenn Morris <rgm@gnu.org>
>> Date:   Thu Mar 17 00:14:11 2016 -0700
>
> After each "git pull", I've done a "make distclean && make".
>
>> Can we be absolutely clear here, please.  Have you observed this bug in
>> Java Mode yourself?
>
> Yes. I've created a new file called test.java with the following
> contents:
>
>> package Test;
>> 
>> public class A extends B<T>$
>
> Pressing enter at this point will trigger a similar error, and the same
> will typing { following that enter.
>
>> I suspect the interface between CC Mode and csharp-mode.  :-)
>> 
>> My working hypothesis is that the compiled csharp-mode.elc was compiled
>> on an earlier revision of the emacs-25 branch, hence didn't pick up a
>> newly introduced c-lang-defvar properly, thus leaving its value at nil.
>> This nil value is what triggered the error in
>> c-forward-<>-arglist-recur.
>
> That's a good theory and I decided to completely wiping csharp-mode and
> reevaluating it inside Emacs to verify that stale data is not the cause
> of the errors.
>
> I'm still getting "wrong argument: stringp, nil" everywhere when
> pressing enter interactively inside Emacs csharp-mode buffers.
>
> I therefore tried to look into the build-system to see what it reports.
>
> Byte-compiling csharp-mode triggers a warning which so far haven't been
> an
> issue for csharp-mode:
>
>> $ make csharp-mode.elc
>> ...
>> csharp-mode.el:1772:17:Warning: looking-back called with 1 argument, but
>>     requires 2-3
>
> Trying to run a "make test" of csharp-mode against git master, most of
> the tests breaks:
>
>> Test indentation-rules-should-be-as-specified-in-test-doc backtrace:
>>   c-forward-label()
>>   c-guess-basic-syntax()
>>   c-indent-region(1 1390)
>>   indent-region(1 1390)
>>   (let* ((buffer (find-file "test-files/indentation-tests.cs")) (orig-
>>   (lambda nil (let* ((buffer (find-file "test-files/indentation-tests.
>>   ert--run-test-internal([cl-struct-ert--test-execution-info [cl-struc
>>   ert-run-test([cl-struct-ert-test indentation-rules-should-be-as-spec
>>   ert-run-or-rerun-test([cl-struct-ert--stats t [[cl-struct-ert-test a
>>   ert-run-tests(t #[385 "\306\307\"\203G\211\211G\310U\203\211@\20
>>   ert-run-tests-batch(nil)
>>   ert-run-tests-batch-and-exit()
>>   command-line-1(("-L" "." "-l" "csharp-mode-tests.el" "-f" "ert-run-t
>>   command-line()
>>   normal-top-level()
>> Test indentation-rules-should-be-as-specified-in-test-doc condition:
>>     (wrong-type-argument stringp nil)
>>    FAILED  15/15  indentation-rules-should-be-as-specified-in-test-doc
>
> I haven't looked into Saulius's C# file to reproduce this issue, so I
> can't say if that is why you cannot reproduce or not.
>
> Are the changes between between Emacs-25 and master so significant that
> they could the big differences between our observations? I find that
> hard to believe.
>
> Anyway, something somewhere is clearly broken, and the faster we can
> find out what, the better.
>
> If you need more input, more theories tested, or more help understanding
> any part of my setup, let me know. I'll try to provide all the info I
> can.

Actually, removing and installing csharp-mode from package manager with
the latest emacs-25 fixed the issue for me. And I could not replicate
the same problem in Java mode.

-- 
Saulius Menkevičius (saulius.menkevicius@gmail.com)





reply via email to

[Prev in Thread] Current Thread [Next in Thread]