GNU bug report logs - #636
23.0.60; Read syntax error while byte-compiling

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (Emacs bug Tracking System)
To: Chong Yidong <cyd <at> stupidchicken.com>
Subject: bug#636: marked as done (23.0.60; Read syntax error while 
 byte-compiling)

[Message part 1 (text/plain, inline)]

Your message dated Mon, 11 Aug 2008 17:42:22 -0400
with message-id <87bpzzfcu9.fsf <at> stupidchicken.com>
and subject line Re: bug#636: Please fix before the release of 23.1
has caused the Emacs bug report #636,
regarding 23.0.60; Read syntax error while byte-compiling
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact don <at> donarmstrong.com
immediately.)


-- 
636: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=636
Emacs Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Dmitry Dzhus <dima <at> sphinx.net.ru>
To: emacs-pretest-bug <at> gnu.org
Subject: 23.0.60; Read syntax error while byte-compiling
Date: Fri, 01 Aug 2008 11:43:43 +0400

The problem occurs when one tries to byte-compile a file with the
following contents (note the newline after `eval-when-compile`):

    (eval-when-compile
       (require 'cc-mode))

Using this command:

    emacs -q --batch -f batch-byte-compile file.el

Which fails with error:

    In toplevel form:
    test1.el:2:19:Error: Invalid read syntax: ")"

Visiting this file in Emacs and attempting to byte-compile it using the
`M-x byte-compile-file RET` command results in the same error being
shown in *Compile-Log* buffer.
    
In the same time, if there is no newline after `eval-when-compile`, e.g.

    (eval-when-compile (require 'cc-mode))

Byte-compiling proceeds successfully. The problem occurs only if one
requires `cc-mode`. Probably this is somehow related with `cc-bytecomp`
module.

In GNU Emacs 23.0.60.1 (i686-pc-linux-gnu, GTK+ Version 2.12.11)
 of 2008-07-30 on blizzard

Windowing system distributor `The X.Org Foundation', version
 11.0.10402000

configured using `configure '--prefix=/usr' '--host=i686-pc-linux-gnu'
'--mandir=/usr/share/man' '--infodir=/usr/share/info'
'--datadir=/usr/share' '--sysconfdir=/etc' '--localstatedir=/var/lib'
'--program-suffix=-emacs-23' '--infodir=/usr/share/info/emacs-23'
'--without-carbon' '--with-sound' '--with-x'
'--with-toolkit-scroll-bars' '--with-gif' '--with-jpeg' '--with-png'
'--with-rsvg' '--with-tiff' '--with-xpm' '--enable-font-backend'
'--with-freetype' '--with-xft' '--without-libotf' '--without-m17n-flt'
'--with-x-toolkit=gtk' '--without-hesiod' '--without-kerberos'
'--without-kerberos5' '--with-gpm' '--with-dbus'
'--build=i686-pc-linux-gnu' 'build_alias=i686-pc-linux-gnu'
'host_alias=i686-pc-linux-gnu' 'CFLAGS=-O2 -march=native -pipe'
'LDFLAGS=-Wl,-O1''

Important settings:
  value of $LC_ALL: 
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: C
  value of $LC_TIME: nil
  value of $LANG: ru_RU.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default-enable-multibyte-characters: t
-- 
Happy Hacking.

http://sphinx.net.ru
む

[Message part 3 (message/rfc822, inline)]

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Alan Mackenzie <acm <at> muc.de>
Cc: Ulrich Mueller <ulm <at> gentoo.org>, 636-done <at> debbugs.gnu.org,
        emacs-devel <at> gnu.org, Glenn Morris <rgm <at> gnu.org>,
        Michael Olson <mwolson <at> gnu.org>
Subject: Re: bug#636: Please fix before the release of 23.1
Date: Mon, 11 Aug 2008 17:42:22 -0400

Alan Mackenzie <acm <at> muc.de> writes:

> The way I see it, it's a bug in `beginning-of-defun'.  The docstring
> says that a non-nil `beginning-of-defun-function' finds the pertinent
> place, but beginning-of-defun then moves point somewhere else.  I HATE
> things that are ostensibly "helpful", but in reality are dumbing down,
> and mainly just foul things up.

This is part of the baggage in beginning-of-defun regarding whether
column zero is the beginning of a defun.  Changing this now might be
unwise, so for the moment I've simply revised the docstring of
beginning-of-defun for extra clarity.

I've also changed cc-defs.el to use beginning-of-defun-raw, which is a
more direct and side-effect free test of beginning-of-defun-function,
and added a save-excursion for extra plus safety ;-)

[Also, closing bug#636.]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.