[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 <agrambot@gmail.com> 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
> README?
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.
- bug#24402: should-error doesn't catch all errors, (continued)
- bug#24402: should-error doesn't catch all errors, Alex, 2017/07/11
- bug#24402: should-error doesn't catch all errors, npostavs, 2017/07/12
- bug#24402: should-error doesn't catch all errors, Alex, 2017/07/12
- bug#24402: should-error doesn't catch all errors, npostavs, 2017/07/12
- bug#24402: should-error doesn't catch all errors, Alex, 2017/07/12
- bug#24402: should-error doesn't catch all errors, npostavs, 2017/07/12
- bug#24402: should-error doesn't catch all errors, Alex, 2017/07/13
- bug#24402: should-error doesn't catch all errors, npostavs, 2017/07/13
- bug#24402: should-error doesn't catch all errors, Alex, 2017/07/14
- bug#24402: should-error doesn't catch all errors, Alex, 2017/07/14
- bug#24402: should-error doesn't catch all errors,
npostavs <=
- bug#24402: should-error doesn't catch all errors, Alex, 2017/07/15
- bug#24402: should-error doesn't catch all errors, npostavs, 2017/07/16
- bug#24402: should-error doesn't catch all errors, Gemini Lasswell, 2017/07/19
- bug#24402: should-error doesn't catch all errors, Alex, 2017/07/19
- bug#24402: should-error doesn't catch all errors, npostavs, 2017/07/19
- bug#24402: should-error doesn't catch all errors, Alex, 2017/07/20
- bug#24402: should-error doesn't catch all errors, Gemini Lasswell, 2017/07/20