commit 9f7bfb6cb06f1480a0904184cabf187e03628e55 (HEAD, refs/remotes/origin/master) Author: Paul Eggert Date: Tue May 26 00:47:24 2020 -0700 Port struct Lisp_FLoat to oddball platforms * src/lisp.h (struct Lisp_Float): Declare via GCALIGNED_UNION_MEMBER, not via GCALIGNED_STRUCT, since alloc.c creates these in arrays and GCALIGNED_STRUCT does not necessarily suffice to align struct Lisp_Float when it’s used in an array. This avoids undefined behavior on oddball machines where sizeof (struct Lisp_Float) is not a multiple of 8 and the compiler does not support __attribute__ ((aligned 8)). diff --git a/src/lisp.h b/src/lisp.h index 8bd83a888c..f5d581a2f1 100644 --- a/src/lisp.h +++ b/src/lisp.h @@ -2801,8 +2801,10 @@ struct Lisp_Float { double data; struct Lisp_Float *chain; + GCALIGNED_UNION_MEMBER } u; - } GCALIGNED_STRUCT; + }; +verify (GCALIGNED (struct Lisp_Float)); INLINE bool (FLOATP) (Lisp_Object x) commit c4faf78a985aa8a147b4a5f7530ea43d0ad55835 Author: Paul Eggert Date: Mon May 25 23:24:47 2020 -0700 Move union emacs_align_type to alloc.c * src/alloc.c (union emacs_align_type): Move to here ... * src/lisp.h: ... from here, and uncomment out some of the types that alloc.c can see but lisp.h cannot. diff --git a/src/alloc.c b/src/alloc.c index 77d5d2839a..f8609398a3 100644 --- a/src/alloc.c +++ b/src/alloc.c @@ -104,6 +104,46 @@ along with GNU Emacs. If not, see . */ #include "w32heap.h" /* for sbrk */ #endif +/* A type with alignment at least as large as any object that Emacs + allocates. This is not max_align_t because some platforms (e.g., + mingw) have buggy malloc implementations that do not align for + max_align_t. This union contains types of all GCALIGNED_STRUCT + components visible here. */ +union emacs_align_type +{ + struct frame frame; + struct Lisp_Bignum Lisp_Bignum; + struct Lisp_Bool_Vector Lisp_Bool_Vector; + struct Lisp_Char_Table Lisp_Char_Table; + struct Lisp_CondVar Lisp_CondVar; + struct Lisp_Finalizer Lisp_Finalizer; + struct Lisp_Float Lisp_Float; + struct Lisp_Hash_Table Lisp_Hash_Table; + struct Lisp_Marker Lisp_Marker; + struct Lisp_Misc_Ptr Lisp_Misc_Ptr; + struct Lisp_Mutex Lisp_Mutex; + struct Lisp_Overlay Lisp_Overlay; + struct Lisp_Sub_Char_Table Lisp_Sub_Char_Table; + struct Lisp_Subr Lisp_Subr; + struct Lisp_User_Ptr Lisp_User_Ptr; + struct Lisp_Vector Lisp_Vector; + struct terminal terminal; + struct thread_state thread_state; + struct window window; + + /* Omit the following since they would require including process.h + etc. In practice their alignments never exceed that of the + structs already listed. */ +#if 0 + struct Lisp_Module_Function Lisp_Module_Function; + struct Lisp_Process Lisp_Process; + struct save_window_data save_window_data; + struct scroll_bar scroll_bar; + struct xwidget_view xwidget_view; + struct xwidget xwidget; +#endif +}; + /* MALLOC_SIZE_NEAR (N) is a good number to pass to malloc when allocating a block of memory with size close to N bytes. For best results N should be a power of 2. diff --git a/src/lisp.h b/src/lisp.h index 937052f6df..8bd83a888c 100644 --- a/src/lisp.h +++ b/src/lisp.h @@ -278,7 +278,7 @@ error !; and does not contain a GC-aligned struct or union, putting GCALIGNED_STRUCT after its closing '}' can help the compiler generate better code. Also, such structs should be added to the - emacs_align_type union. + emacs_align_type union in alloc.c. Although these macros are reasonably portable, they are not guaranteed on non-GCC platforms, as C11 does not require support @@ -5060,46 +5060,6 @@ maybe_gc (void) maybe_garbage_collect (); } -/* A type with alignment at least as large as any object that Emacs - allocates. This is not max_align_t because some platforms (e.g., - mingw) have buggy malloc implementations that do not align for - max_align_t. This union contains types of all GCALIGNED_STRUCT - components visible here. */ -union emacs_align_type -{ - struct Lisp_Bool_Vector Lisp_Bool_Vector; - struct Lisp_Char_Table Lisp_Char_Table; - struct Lisp_CondVar Lisp_CondVar; - struct Lisp_Finalizer Lisp_Finalizer; - struct Lisp_Float Lisp_Float; - struct Lisp_Hash_Table Lisp_Hash_Table; - struct Lisp_Marker Lisp_Marker; - struct Lisp_Misc_Ptr Lisp_Misc_Ptr; - struct Lisp_Mutex Lisp_Mutex; - struct Lisp_Overlay Lisp_Overlay; - struct Lisp_Sub_Char_Table Lisp_Sub_Char_Table; - struct Lisp_Subr Lisp_Subr; - struct Lisp_User_Ptr Lisp_User_Ptr; - struct Lisp_Vector Lisp_Vector; - struct thread_state thread_state; - - /* Omit the following since they would require including bignum.h, - frame.h etc., and in practice their alignments never exceed that - of the structs already listed. */ -#if 0 - struct frame frame; - struct Lisp_Bignum Lisp_Bignum; - struct Lisp_Module_Function Lisp_Module_Function; - struct Lisp_Process Lisp_Process; - struct save_window_data save_window_data; - struct scroll_bar scroll_bar; - struct terminal terminal; - struct window window; - struct xwidget xwidget; - struct xwidget_view xwidget_view; -#endif -}; - INLINE_HEADER_END #endif /* EMACS_LISP_H */ commit 92278640babbfe1383ebba3baf3bc10278a01050 Author: Paul Eggert Date: Mon May 25 23:06:07 2020 -0700 Further fix for aborts due to GC losing pseudovectors * src/alloc.c (MALLOC_ALIGNMENT_BOUND): Remove. (LISP_ALIGNMENT): Go back to yesterday’s version, except use union emacs_align_type instead of max_align_t. (MALLOC_IS_LISP_ALIGNED): Go back to yesterday’s version. (maybe_lisp_pointer): Check against GCALIGNMENT, not LISP_ALIGNMENT. * src/lisp.h (union emacs_align_type): Bring back. diff --git a/src/alloc.c b/src/alloc.c index 89fe96a234..77d5d2839a 100644 --- a/src/alloc.c +++ b/src/alloc.c @@ -655,24 +655,22 @@ buffer_memory_full (ptrdiff_t nbytes) #define COMMON_MULTIPLE(a, b) \ ((a) % (b) == 0 ? (a) : (b) % (a) == 0 ? (b) : (a) * (b)) -/* A lower bound on the alignment of malloc. Although this bound is - incorrect for some buggy malloc implementations (e.g., MinGW circa - 2020), the bugs should not matter for the way this bound is used - since the correct bound is also a multiple of LISP_ALIGNMENT on the - buggy platforms. */ -enum { MALLOC_ALIGNMENT_BOUND = alignof (max_align_t) }; - -/* A lower bound on the alignment of Lisp objects allocated on the heap. - All such objects must have an address that is a multiple of LISP_ALIGNMENT; - otherwise maybe_lisp_pointer can issue false negatives, causing crashes. - On all practical Emacs targets, sizeof (struct Lisp_Float) == 8 and - since GCALIGNMENT also equals 8 there's little point to optimizing - for impractical targets. */ -enum { LISP_ALIGNMENT = GCALIGNMENT }; +/* Alignment needed for memory blocks that are allocated via malloc + and that contain Lisp objects. On typical hosts malloc already + aligns sufficiently, but extra work is needed on oddball hosts + where Emacs would crash if malloc returned a non-GCALIGNED pointer. */ +enum { LISP_ALIGNMENT = alignof (union { union emacs_align_type x; + GCALIGNED_UNION_MEMBER }) }; +verify (LISP_ALIGNMENT % GCALIGNMENT == 0); /* True if malloc (N) is known to return storage suitably aligned for - Lisp objects whenever N is a multiple of LISP_ALIGNMENT. */ -enum { MALLOC_IS_LISP_ALIGNED = MALLOC_ALIGNMENT_BOUND % LISP_ALIGNMENT == 0 }; + Lisp objects whenever N is a multiple of LISP_ALIGNMENT. In + practice this is true whenever alignof (max_align_t) is also a + multiple of LISP_ALIGNMENT. This works even for buggy platforms + like MinGW circa 2020, where alignof (max_align_t) is 16 even though + the malloc alignment is only 8, and where Emacs still works because + it never does anything that requires an alignment of 16. */ +enum { MALLOC_IS_LISP_ALIGNED = alignof (max_align_t) % LISP_ALIGNMENT == 0 }; /* If compiled with XMALLOC_BLOCK_INPUT_CHECK, define a symbol BLOCK_INPUT_IN_MEMORY_ALLOCATORS that is visible to the debugger. @@ -4653,12 +4651,12 @@ mark_maybe_objects (Lisp_Object const *array, ptrdiff_t nelts) collected, and false otherwise (i.e., false if it is easy to see that P cannot point to Lisp data that can be garbage collected). Symbols are implemented via offsets not pointers, but the offsets - are also multiples of LISP_ALIGNMENT. */ + are also multiples of GCALIGNMENT. */ static bool maybe_lisp_pointer (void *p) { - return (uintptr_t) p % LISP_ALIGNMENT == 0; + return (uintptr_t) p % GCALIGNMENT == 0; } /* If P points to Lisp data, mark that as live if it isn't already diff --git a/src/lisp.h b/src/lisp.h index 85bdc172b2..937052f6df 100644 --- a/src/lisp.h +++ b/src/lisp.h @@ -277,7 +277,8 @@ error !; allocation in a containing union that has GCALIGNED_UNION_MEMBER) and does not contain a GC-aligned struct or union, putting GCALIGNED_STRUCT after its closing '}' can help the compiler - generate better code. + generate better code. Also, such structs should be added to the + emacs_align_type union. Although these macros are reasonably portable, they are not guaranteed on non-GCC platforms, as C11 does not require support @@ -5059,6 +5060,46 @@ maybe_gc (void) maybe_garbage_collect (); } +/* A type with alignment at least as large as any object that Emacs + allocates. This is not max_align_t because some platforms (e.g., + mingw) have buggy malloc implementations that do not align for + max_align_t. This union contains types of all GCALIGNED_STRUCT + components visible here. */ +union emacs_align_type +{ + struct Lisp_Bool_Vector Lisp_Bool_Vector; + struct Lisp_Char_Table Lisp_Char_Table; + struct Lisp_CondVar Lisp_CondVar; + struct Lisp_Finalizer Lisp_Finalizer; + struct Lisp_Float Lisp_Float; + struct Lisp_Hash_Table Lisp_Hash_Table; + struct Lisp_Marker Lisp_Marker; + struct Lisp_Misc_Ptr Lisp_Misc_Ptr; + struct Lisp_Mutex Lisp_Mutex; + struct Lisp_Overlay Lisp_Overlay; + struct Lisp_Sub_Char_Table Lisp_Sub_Char_Table; + struct Lisp_Subr Lisp_Subr; + struct Lisp_User_Ptr Lisp_User_Ptr; + struct Lisp_Vector Lisp_Vector; + struct thread_state thread_state; + + /* Omit the following since they would require including bignum.h, + frame.h etc., and in practice their alignments never exceed that + of the structs already listed. */ +#if 0 + struct frame frame; + struct Lisp_Bignum Lisp_Bignum; + struct Lisp_Module_Function Lisp_Module_Function; + struct Lisp_Process Lisp_Process; + struct save_window_data save_window_data; + struct scroll_bar scroll_bar; + struct terminal terminal; + struct window window; + struct xwidget xwidget; + struct xwidget_view xwidget_view; +#endif +}; + INLINE_HEADER_END #endif /* EMACS_LISP_H */ commit 3abf76da564ff8526bbcba6b92dfb7b97cb87779 Author: Paul Eggert Date: Mon May 25 22:06:25 2020 -0700 Refix aborts due to GC losing pseudovectors This is simpler, and fixes a bug in the previous fix. * src/alloc.c (MALLOC_ALIGNMENT_BOUND): Simplify by using max_align_t, since the buggy implementations won’t break this simpler implementation. (LISP_ALIGNMENT): Simplify by just using GCALIGNMENT, since the fancier implementation wasn’t correct anyway, and fixing it isn’t worth the trouble on practical platforms. * src/lisp.h (union emacs_align_type): Remove. diff --git a/src/alloc.c b/src/alloc.c index 602282e570..89fe96a234 100644 --- a/src/alloc.c +++ b/src/alloc.c @@ -655,26 +655,20 @@ buffer_memory_full (ptrdiff_t nbytes) #define COMMON_MULTIPLE(a, b) \ ((a) % (b) == 0 ? (a) : (b) % (a) == 0 ? (b) : (a) * (b)) -/* A lower bound on the alignment of malloc. For better performance - this bound should be tighter. For glibc 2.26 and later a tighter - bound is known. */ -#if 2 < __GLIBC__ + (26 <= __GLIBC_MINOR__) -enum { MALLOC_ALIGNMENT_BOUND = MALLOC_ALIGNMENT }; -#else -/* A bound known to work for all Emacs porting targets. Tightening - this looser bound by using max_align_t instead of long long int - would break buggy malloc implementations like MinGW circa 2020. */ -enum { MALLOC_ALIGNMENT_BOUND = alignof (long long int) }; -#endif - -/* A lower bound on the alignment of Lisp objects. All Lisp objects - must have an address that is a multiple of LISP_ALIGNMENT; +/* A lower bound on the alignment of malloc. Although this bound is + incorrect for some buggy malloc implementations (e.g., MinGW circa + 2020), the bugs should not matter for the way this bound is used + since the correct bound is also a multiple of LISP_ALIGNMENT on the + buggy platforms. */ +enum { MALLOC_ALIGNMENT_BOUND = alignof (max_align_t) }; + +/* A lower bound on the alignment of Lisp objects allocated on the heap. + All such objects must have an address that is a multiple of LISP_ALIGNMENT; otherwise maybe_lisp_pointer can issue false negatives, causing crashes. - It's good to make this bound tight: if Lisp objects are always - aligned more strictly than LISP_ALIGNMENT, maybe_lisp_pointer will - issue more false positives, hurting performance. */ -enum { LISP_ALIGNMENT = max (max (GCALIGNMENT, MALLOC_ALIGNMENT_BOUND), - alignof (union emacs_align_type)) }; + On all practical Emacs targets, sizeof (struct Lisp_Float) == 8 and + since GCALIGNMENT also equals 8 there's little point to optimizing + for impractical targets. */ +enum { LISP_ALIGNMENT = GCALIGNMENT }; /* True if malloc (N) is known to return storage suitably aligned for Lisp objects whenever N is a multiple of LISP_ALIGNMENT. */ diff --git a/src/lisp.h b/src/lisp.h index 937052f6df..85bdc172b2 100644 --- a/src/lisp.h +++ b/src/lisp.h @@ -277,8 +277,7 @@ error !; allocation in a containing union that has GCALIGNED_UNION_MEMBER) and does not contain a GC-aligned struct or union, putting GCALIGNED_STRUCT after its closing '}' can help the compiler - generate better code. Also, such structs should be added to the - emacs_align_type union. + generate better code. Although these macros are reasonably portable, they are not guaranteed on non-GCC platforms, as C11 does not require support @@ -5060,46 +5059,6 @@ maybe_gc (void) maybe_garbage_collect (); } -/* A type with alignment at least as large as any object that Emacs - allocates. This is not max_align_t because some platforms (e.g., - mingw) have buggy malloc implementations that do not align for - max_align_t. This union contains types of all GCALIGNED_STRUCT - components visible here. */ -union emacs_align_type -{ - struct Lisp_Bool_Vector Lisp_Bool_Vector; - struct Lisp_Char_Table Lisp_Char_Table; - struct Lisp_CondVar Lisp_CondVar; - struct Lisp_Finalizer Lisp_Finalizer; - struct Lisp_Float Lisp_Float; - struct Lisp_Hash_Table Lisp_Hash_Table; - struct Lisp_Marker Lisp_Marker; - struct Lisp_Misc_Ptr Lisp_Misc_Ptr; - struct Lisp_Mutex Lisp_Mutex; - struct Lisp_Overlay Lisp_Overlay; - struct Lisp_Sub_Char_Table Lisp_Sub_Char_Table; - struct Lisp_Subr Lisp_Subr; - struct Lisp_User_Ptr Lisp_User_Ptr; - struct Lisp_Vector Lisp_Vector; - struct thread_state thread_state; - - /* Omit the following since they would require including bignum.h, - frame.h etc., and in practice their alignments never exceed that - of the structs already listed. */ -#if 0 - struct frame frame; - struct Lisp_Bignum Lisp_Bignum; - struct Lisp_Module_Function Lisp_Module_Function; - struct Lisp_Process Lisp_Process; - struct save_window_data save_window_data; - struct scroll_bar scroll_bar; - struct terminal terminal; - struct window window; - struct xwidget xwidget; - struct xwidget_view xwidget_view; -#endif -}; - INLINE_HEADER_END #endif /* EMACS_LISP_H */ commit 0dc529175dc027c1567fb9b7cd529d29236aad44 Author: Paul Eggert Date: Mon May 25 20:26:14 2020 -0700 Fix aborts due to GC losing pseudovectors Problem reported by Eli Zaretskii (Bug#41321). * src/alloc.c (MALLOC_ALIGNMENT_BOUND): New constant. (LISP_ALIGNMENT): Lower it to avoid crashes on MinGW and similarly buggy platforms where malloc returns pointers not aligned to alignof (max_align_t). But keep it higher on platforms where this is known to work, as it helps GC performance. (MALLOC_IS_LISP_ALIGNED): Define in terms of the other two. * src/alloc.c (stacktop_sentry): * src/thread.c (run_thread): Don’t overalign or oversize stack sentries; they need to be aligned only for pointers and Lisp_Object, not for arbitrary pseudovector contents. * src/lisp.h (union emacs_align_type): New type, used for LISP_ALIGNMENT. diff --git a/src/alloc.c b/src/alloc.c index d5a6d9167e..602282e570 100644 --- a/src/alloc.c +++ b/src/alloc.c @@ -112,9 +112,9 @@ along with GNU Emacs. If not, see . */ adds sizeof (size_t) to SIZE for internal overhead, and then rounds up to a multiple of MALLOC_ALIGNMENT. Emacs can improve performance a bit on GNU platforms by arranging for the resulting - size to be a power of two. This heuristic is good for glibc 2.0 - (1997) through at least glibc 2.31 (2020), and does not affect - correctness on other platforms. */ + size to be a power of two. This heuristic is good for glibc 2.26 + (2017) and later, and does not affect correctness on other + platforms. */ #define MALLOC_SIZE_NEAR(n) \ (ROUNDUP (max (n, sizeof (size_t)), MALLOC_ALIGNMENT) - sizeof (size_t)) @@ -655,28 +655,30 @@ buffer_memory_full (ptrdiff_t nbytes) #define COMMON_MULTIPLE(a, b) \ ((a) % (b) == 0 ? (a) : (b) % (a) == 0 ? (b) : (a) * (b)) -/* LISP_ALIGNMENT is the alignment of Lisp objects. It must be at - least GCALIGNMENT so that pointers can be tagged. It also must be - at least as strict as the alignment of all the C types used to - implement Lisp objects; since pseudovectors can contain any C type, - this is max_align_t. On recent GNU/Linux x86 and x86-64 this can - often waste up to 8 bytes, since alignof (max_align_t) is 16 but - typical vectors need only an alignment of 8. Although shrinking - the alignment to 8 would save memory, it cost a 20% hit to Emacs - CPU performance on Fedora 28 x86-64 when compiled with gcc -m32. */ -enum { LISP_ALIGNMENT = alignof (union { max_align_t x; - GCALIGNED_UNION_MEMBER }) }; -verify (LISP_ALIGNMENT % GCALIGNMENT == 0); +/* A lower bound on the alignment of malloc. For better performance + this bound should be tighter. For glibc 2.26 and later a tighter + bound is known. */ +#if 2 < __GLIBC__ + (26 <= __GLIBC_MINOR__) +enum { MALLOC_ALIGNMENT_BOUND = MALLOC_ALIGNMENT }; +#else +/* A bound known to work for all Emacs porting targets. Tightening + this looser bound by using max_align_t instead of long long int + would break buggy malloc implementations like MinGW circa 2020. */ +enum { MALLOC_ALIGNMENT_BOUND = alignof (long long int) }; +#endif + +/* A lower bound on the alignment of Lisp objects. All Lisp objects + must have an address that is a multiple of LISP_ALIGNMENT; + otherwise maybe_lisp_pointer can issue false negatives, causing crashes. + It's good to make this bound tight: if Lisp objects are always + aligned more strictly than LISP_ALIGNMENT, maybe_lisp_pointer will + issue more false positives, hurting performance. */ +enum { LISP_ALIGNMENT = max (max (GCALIGNMENT, MALLOC_ALIGNMENT_BOUND), + alignof (union emacs_align_type)) }; /* True if malloc (N) is known to return storage suitably aligned for - Lisp objects whenever N is a multiple of LISP_ALIGNMENT. In - practice this is true whenever alignof (max_align_t) is also a - multiple of LISP_ALIGNMENT. This works even for x86, where some - platform combinations (e.g., GCC 7 and later, glibc 2.25 and - earlier) have bugs where alignof (max_align_t) is 16 even though - the malloc alignment is only 8, and where Emacs still works because - it never does anything that requires an alignment of 16. */ -enum { MALLOC_IS_LISP_ALIGNED = alignof (max_align_t) % LISP_ALIGNMENT == 0 }; + Lisp objects whenever N is a multiple of LISP_ALIGNMENT. */ +enum { MALLOC_IS_LISP_ALIGNED = MALLOC_ALIGNMENT_BOUND % LISP_ALIGNMENT == 0 }; /* If compiled with XMALLOC_BLOCK_INPUT_CHECK, define a symbol BLOCK_INPUT_IN_MEMORY_ALLOCATORS that is visible to the debugger. @@ -4885,9 +4887,10 @@ test_setjmp (void) as a stack scan limit. */ typedef union { - /* Align the stack top properly. Even if !HAVE___BUILTIN_UNWIND_INIT, - jmp_buf may not be aligned enough on darwin-ppc64. */ - max_align_t o; + /* Make sure stack_top and m_stack_bottom are properly aligned as GC + expects. */ + Lisp_Object o; + void *p; #ifndef HAVE___BUILTIN_UNWIND_INIT sys_jmp_buf j; char c; diff --git a/src/lisp.h b/src/lisp.h index 85bdc172b2..937052f6df 100644 --- a/src/lisp.h +++ b/src/lisp.h @@ -277,7 +277,8 @@ error !; allocation in a containing union that has GCALIGNED_UNION_MEMBER) and does not contain a GC-aligned struct or union, putting GCALIGNED_STRUCT after its closing '}' can help the compiler - generate better code. + generate better code. Also, such structs should be added to the + emacs_align_type union. Although these macros are reasonably portable, they are not guaranteed on non-GCC platforms, as C11 does not require support @@ -5059,6 +5060,46 @@ maybe_gc (void) maybe_garbage_collect (); } +/* A type with alignment at least as large as any object that Emacs + allocates. This is not max_align_t because some platforms (e.g., + mingw) have buggy malloc implementations that do not align for + max_align_t. This union contains types of all GCALIGNED_STRUCT + components visible here. */ +union emacs_align_type +{ + struct Lisp_Bool_Vector Lisp_Bool_Vector; + struct Lisp_Char_Table Lisp_Char_Table; + struct Lisp_CondVar Lisp_CondVar; + struct Lisp_Finalizer Lisp_Finalizer; + struct Lisp_Float Lisp_Float; + struct Lisp_Hash_Table Lisp_Hash_Table; + struct Lisp_Marker Lisp_Marker; + struct Lisp_Misc_Ptr Lisp_Misc_Ptr; + struct Lisp_Mutex Lisp_Mutex; + struct Lisp_Overlay Lisp_Overlay; + struct Lisp_Sub_Char_Table Lisp_Sub_Char_Table; + struct Lisp_Subr Lisp_Subr; + struct Lisp_User_Ptr Lisp_User_Ptr; + struct Lisp_Vector Lisp_Vector; + struct thread_state thread_state; + + /* Omit the following since they would require including bignum.h, + frame.h etc., and in practice their alignments never exceed that + of the structs already listed. */ +#if 0 + struct frame frame; + struct Lisp_Bignum Lisp_Bignum; + struct Lisp_Module_Function Lisp_Module_Function; + struct Lisp_Process Lisp_Process; + struct save_window_data save_window_data; + struct scroll_bar scroll_bar; + struct terminal terminal; + struct window window; + struct xwidget xwidget; + struct xwidget_view xwidget_view; +#endif +}; + INLINE_HEADER_END #endif /* EMACS_LISP_H */ diff --git a/src/thread.c b/src/thread.c index df1a705382..b638dd77f8 100644 --- a/src/thread.c +++ b/src/thread.c @@ -717,12 +717,17 @@ run_thread (void *state) { /* Make sure stack_top and m_stack_bottom are properly aligned as GC expects. */ - max_align_t stack_pos; + union + { + Lisp_Object o; + void *p; + char c; + } stack_pos; struct thread_state *self = state; struct thread_state **iter; - self->m_stack_bottom = self->stack_top = (char *) &stack_pos; + self->m_stack_bottom = self->stack_top = &stack_pos.c; self->thread_id = sys_thread_self (); if (self->thread_name) commit 8b940dac32c2a37f93b8670751a0e5f72ec86cea Author: Stefan Kangas Date: Tue May 26 04:56:56 2020 +0200 Mark metamail.el as obsolete (Bug#41388) The metamail package was last released in 1994, and has been removed from most GNU/Linux distributions due to being buggy and unmaintained. * lisp/mail/metamail.el: Move from here... * lisp/obsolete/metamail.el: ...to here. * etc/NEWS: Mention its obsoletion. diff --git a/etc/NEWS b/etc/NEWS index e09f32a7c3..e97755a454 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -405,6 +405,8 @@ Previously 'xml-print' would produce invalid XML when given a string with characters that are not valid in XML (see https://www.w3.org/TR/xml/#charsets). Now it rejects such strings. +** The metamail.el library is now marked obsolete. + * New Modes and Packages in Emacs 28.1 diff --git a/lisp/mail/metamail.el b/lisp/obsolete/metamail.el similarity index 99% rename from lisp/mail/metamail.el rename to lisp/obsolete/metamail.el index 0e407ea060..d6ab4a3d0c 100644 --- a/lisp/mail/metamail.el +++ b/lisp/obsolete/metamail.el @@ -4,6 +4,7 @@ ;; Author: Masanobu UMEDA ;; Keywords: mail, news, mime, multimedia +;; Obsolete-since: 28.1 ;; This file is part of GNU Emacs. commit 3f66908ee0821d638ec9bf4360400cbd2e58f70a Author: Dmitry Gutov Date: Mon May 25 22:29:47 2020 +0300 Bump project.el version * project.el: Bump the version diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el index 9c100ad218..88f73e4fb3 100644 --- a/lisp/progmodes/project.el +++ b/lisp/progmodes/project.el @@ -1,7 +1,7 @@ ;;; project.el --- Operations on the current project -*- lexical-binding: t; -*- ;; Copyright (C) 2015-2020 Free Software Foundation, Inc. -;; Version: 0.2.0 +;; Version: 0.3.0 ;; Package-Requires: ((emacs "26.3")) ;; This is a GNU ELPA :core package. Avoid using functionality that commit c0275555f201b52a7f1184cf89937acd6e1f59ad Author: Dmitry Gutov Date: Mon May 25 22:29:06 2020 +0300 ; More the note about reporting problems further up diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el index c72e9d94b1..9c100ad218 100644 --- a/lisp/progmodes/project.el +++ b/lisp/progmodes/project.el @@ -24,6 +24,11 @@ ;;; Commentary: +;; NOTE: The project API is still experimental and can change in major, +;; backward-incompatible ways. Everyone is encouraged to try it, and +;; report to us any problems or use cases we hadn't anticipated, by +;; sending an email to emacs-devel, or `M-x report-emacs-bug'. +;; ;; This file contains generic infrastructure for dealing with ;; projects, some utility functions, and commands using that ;; infrastructure. @@ -32,11 +37,6 @@ ;; current project, without having to know which package handles ;; detection of that project type, parsing its config files, etc. ;; -;; NOTE: The project API is still experimental and can change in major, -;; backward-incompatible ways. Everyone is encouraged to try it, and -;; report to us any problems or use cases we hadn't anticipated, by -;; sending an email to emacs-devel, or `M-x report-emacs-bug'. -;; ;; Infrastructure: ;; ;; Function `project-current', to determine the current project commit 448fe7ad250fd5501d363c1b3355bfdbc7c71550 Author: Philipp Stephani Date: Mon May 25 21:21:31 2020 +0200 ; * lisp/files.el (auto-save-visited-mode): Fix typo in last commit. diff --git a/lisp/files.el b/lisp/files.el index cb37047649..cefae20ab5 100644 --- a/lisp/files.el +++ b/lisp/files.el @@ -433,7 +433,7 @@ to the visited files directly and will also run all save-related hooks. See Info node `Saving' for details of the save process. You can also set the buffer-local value of the variable -`auto-save-visted-mode' to nil. A buffer where the buffer-local +`auto-save-visited-mode' to nil. A buffer where the buffer-local value of this variable is nil is ignored for the purpose of `auto-save-visited-mode', even if `auto-save-visited-mode' is enabled." commit f8e99938ec41a9af8d42b2ed78af1370fc2c1bc2 Author: Philipp Stephani Date: Wed Apr 1 19:54:01 2020 +0200 Allow inhibiting 'auto-save-visited-mode' on a per-buffer basis. At least for me, 'auto-save-visited-mode' is very slow and blocks user interaction for files visited over TRAMP. Therefore, I'd like a mechanism to disable it for some buffers (namely, those visiting remote files). * (auto-save-visited-mode): Document that 'auto-save-visited-mode' can be set to nil buffer-locally. * etc/NEWS: Document new behavior. diff --git a/etc/NEWS b/etc/NEWS index 4bc00cc337..e09f32a7c3 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -98,6 +98,9 @@ shows equivalent key bindings for all commands that have them. 'gomoku-move-sw' and 'gomoku-move-ne' now work correctly, and horizontal movements now stop at the edge of the board. +** Autosaving via 'auto-save-visited-mode' can now be inhibited by +setting the variable 'auto-save-visited-mode' buffer-locally to nil. + * Changes in Specialized Modes and Packages in Emacs 28.1 diff --git a/lisp/files.el b/lisp/files.el index dba704f7a4..cb37047649 100644 --- a/lisp/files.el +++ b/lisp/files.el @@ -430,7 +430,13 @@ idle for `auto-save-visited-interval' seconds." Unlike `auto-save-mode', this mode will auto-save buffer contents to the visited files directly and will also run all save-related -hooks. See Info node `Saving' for details of the save process." +hooks. See Info node `Saving' for details of the save process. + +You can also set the buffer-local value of the variable +`auto-save-visted-mode' to nil. A buffer where the buffer-local +value of this variable is nil is ignored for the purpose of +`auto-save-visited-mode', even if `auto-save-visited-mode' is +enabled." :group 'auto-save :global t (when auto-save--timer (cancel-timer auto-save--timer)) @@ -441,6 +447,7 @@ hooks. See Info node `Saving' for details of the save process." #'save-some-buffers :no-prompt (lambda () (and buffer-file-name + auto-save-visited-mode (not (and buffer-auto-save-file-name auto-save-visited-file-name)))))))) commit c812223c9fc2684d0edc9cb848cfa6d83c6fdb9a Author: Lars Ingebrigtsen Date: Mon May 25 15:03:37 2020 +0200 Don't bug out in xml-escape-string if invalid characters aren't present * lisp/xml.el (xml-escape-string): Don't bug out if invalid characters aren't present. diff --git a/lisp/xml.el b/lisp/xml.el index 767cf04284..10ef8e2087 100644 --- a/lisp/xml.el +++ b/lisp/xml.el @@ -1032,7 +1032,8 @@ by https://www.w3.org/TR/xml/#charsets), signal an error of type (insert string) (goto-char (point-min)) (when (re-search-forward - "[^\u0009\u000A\u000D\u0020-\uD7FF\uE000-\uFFFD\U00010000-\U0010FFFF]") + "[^\u0009\u000A\u000D\u0020-\uD7FF\uE000-\uFFFD\U00010000-\U0010FFFF]" + nil t) (signal 'xml-invalid-character (list (char-before) (match-beginning 0)))) (dolist (substitution '(("&" . "&") ("<" . "<")