From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30247 invoked by alias); 10 Jun 2009 02:14:26 -0000 Received: (qmail 30239 invoked by uid 22791); 10 Jun 2009 02:14:25 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=BAYES_00,J_CHICKENPOX_72,SPF_PASS,WEIRD_PORT X-Spam-Check-By: sourceware.org Received: from qw-out-1920.google.com (HELO qw-out-1920.google.com) (74.125.92.149) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 10 Jun 2009 02:14:20 +0000 Received: by qw-out-1920.google.com with SMTP id 4so281671qwk.14 for ; Tue, 09 Jun 2009 19:14:17 -0700 (PDT) Received: by 10.224.2.74 with SMTP id 10mr1037722qai.259.1244599562451; Tue, 09 Jun 2009 19:06:02 -0700 (PDT) Received: from ?192.168.0.2? (d-132-204-221-119.res.umontreal.ca [132.204.221.119]) by mx.google.com with ESMTPS id 7sm654832qwb.6.2009.06.09.19.05.59 (version=SSLv3 cipher=RC4-MD5); Tue, 09 Jun 2009 19:06:00 -0700 (PDT) Message-ID: <4A2F1506.5090905@gmail.com> Date: Wed, 10 Jun 2009 02:14:00 -0000 From: Taras Glek User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: Diego Novillo CC: gcc@gcc.gnu.org Subject: Re: plugin callbacks after compiler errors References: <4A2EB8F4.2080003@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2009-06/txt/msg00221.txt.bz2 Diego Novillo wrote: > On Tue, Jun 9, 2009 at 15:33, Taras Glek wrote: > >> While developing my plugin I've noticed that many callbacks need to be >> guarded with "if (errorcount)" or the plugin will cause a gcc crash due to >> receiving less complete data than it expected. >> > > More details please. What exactly is the error and how is errorcount related? > > >> Should the plugin API guard callbacks in invoke_plugin_callbacks() to avoid >> 99% of plugins running into this issue? >> > > At the point that plugins are invoked, they should be able to deal > with whatever state the IL is at that moment. I'd favor flexibility > over protection here. But I'd like to see more details on what you're > after here. > This is more of a polish issue than anything else. Trouble is that one may never see these bugs during plugin development unless the plugins are tested on files that have syntax errors. Test command: /home/bradh/devel/gcc-build/gcc/cc1 -quiet -O1 -ftest-coverage -fplugin=../gcc_dehydra.so -o /dev/null -fplugin-arg-gcc_dehydra-=test_numinfo.js numinfo.cc Failure msg: Expected 'OK' output; Errors: numinfo.cc:14:6: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘boolvar’ numinfo.cc:19:7: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘enumvar’ numinfo.cc:21:7: error: expected identifier or ‘(’ before ‘&’ token numinfo.cc:22:21: error: ‘enumvar’ undeclared here (not in a function) *** WARNING *** there are active plugins, do not report this as a bug unless you can reproduce it without enabling any plugins. Event Plugins PLUGIN_FINISH_TYPE gcc_dehydra PLUGIN_FINISH_UNIT gcc_dehydra PLUGIN_CXX_CP_PRE_GENERICIZE gcc_dehydra PLUGIN_FINISH gcc_dehydra PLUGIN_EVENT_LAST gcc_dehydra plugin_init gcc_dehydra numinfo.cc:22:1: internal compiler error: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in process_type, at dehydra_plugin.c:139 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. Stuff like FINISH_TYPE, PLUGIN_CXX_CP_PRE_GENERICIZE, etc can end up with error nodes instead of what is normally expected to be there. I can't imagine a usecase for when it would be useful for a plugin to have the error marker node. As I said, it's a minor polish issue. It may be sufficient to just have a note in the documentation as Basil suggested. Taras