[Top][All Lists]

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

bug#24402: should-error doesn't catch all errors

From: npostavs
Subject: bug#24402: should-error doesn't catch all errors
Date: Sat, 15 Jul 2017 17:57:14 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2.50 (gnu/linux)

Alex <address@hidden> writes:

> The segfault appears to have been because I didn't wipe out the elc
> files when testing different implementations.

I suspect getting a segfault might indicate an actual bug somewhere.

> I spent a lot longer than I'd like to admit finding this out. Is there a
> reason why "make clean" in the test directory doesn't wipe out elc
> files? I don't understand why there's a separate bootstrap-clean that
> does this. Can this and TEST_LOAD_EL please be documented in the test

I think it was basically copied from the other Makefiles, where cleaning
all elc files would mean a very long subsequent compilation.  It might
make sense to break the pattern for the test/ subdirectory though.

> Anyway, I got everything back in order. Sadly, there's a couple extra
> tests that now fail for me in the patch that *doesn't* expand inline
> functions, and these don't fail for me in a clean master. They are in
> eieio-tests (23 and 24).

I'm seeing eieio-tests failing also in master.  This seems to be an
actual bug, in the definition of `cl-typep' I think.  I've opened a new
bug for this (Bug#27718).

> With the inline expansion, I also get some errors in ert-tests. All of
> the errors, with the exception of subr-tests error, seem to be from
> cl-defstruct and cl-typep (which is defined by define-inline).
> Do you have any ideas? There should be 5 unexpected errors without the
> inline expansion, and 6 errors with it. Note that all tests pass in both
> cases without "TEST_LOAD_EL=no".
> If it's easy to fix the eieio tests and not the other ones, then it
> might be better to leave the inline-function expansion out for now.

I have a fix for the subr-tests failed, as for the others, I don't know
enough about the compilation process to untangle it yet.  I think we
should just leave the inline-function expansion part out for now, at
which point I believe your patch won't be making anything worse, so it
should be okay to install.

reply via email to

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