From patchwork Tue Feb 7 20:32:08 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Christopher Li X-Patchwork-Id: 9561141 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id F13EE60236 for ; Tue, 7 Feb 2017 20:41:43 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id E2F9C28495 for ; Tue, 7 Feb 2017 20:41:43 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id D67442849A; Tue, 7 Feb 2017 20:41:43 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.3 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,RCVD_IN_SORBS_SPAM,T_DKIM_INVALID,T_TVD_MIME_EPI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 7E9D328495 for ; Tue, 7 Feb 2017 20:41:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754199AbdBGUln (ORCPT ); Tue, 7 Feb 2017 15:41:43 -0500 Received: from mail-it0-f66.google.com ([209.85.214.66]:35463 "EHLO mail-it0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752563AbdBGUlm (ORCPT ); Tue, 7 Feb 2017 15:41:42 -0500 Received: by mail-it0-f66.google.com with SMTP id 203so13549828ith.2 for ; Tue, 07 Feb 2017 12:41:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=pM1Fclj4LvNgxBYmEqAY1w3AlNP0XnqCMcT1y7UptIw=; b=qtlPrQ46HZfJJWMqC9iN/ArtNXdtUcCW8EF2MwP5WpsbMxGX8rS0P8WmL9LPqLKEOK zAJQnEhsx55gPI+xzMGjwffuCXCsHo0nfE3gB6qtgtZ/7I76MMxqvTaPzpcY6++PDTwj JNDf+SaKUlAql7eW1k2qRJ3F7OGOWKHnYiFSq+kPpVB02rjEuk682QhaiZ4YgeFtPCGW z7NgzaHnGReMy0Oav9yyE/eNVZdQp4q9skXEowYLUKjALv9OYv3QjxBWqyq1h6uQ77r/ 3ZA+mylnfhS6GkCAJGY+Bk9aVJodZWltE9zUfcPcAGRKHfMUr4Qopllg2OeQdo+4R8Rd oOiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=pM1Fclj4LvNgxBYmEqAY1w3AlNP0XnqCMcT1y7UptIw=; b=kKYip7qWs7DBCdrUPyT0v8zruX5a5NgCutRFTqi2uAelCTeP7bXlQhIInbCBdp2rBp D/fUsivT6IovEcpQjSaC7vibqZ+mdj7Ze8/gP3yJKTpr33XA7NGODoMD/JKbIEHKZwSE CFLj3w1KOyo8m2giHoUXgrCdzykQ1YKIE4nwijTI/REkQquJpaPAimz5V1AETp3L4hVv g7fPL1JF4MmBJXcTG4eAz9QRett7PMwf8+fn0ffocZySFyp+FpGOpcFaXXelJON9/w0K QDRDidtZQYX3V1xLl1nIUsLyTURAO+fTMwjWqN+PoVA7P2IlJ0PiLa4TQyli8aCGN3sH YGBQ== X-Gm-Message-State: AIkVDXJcCwEvZixczc6S+Qm9DzHnOreM5DHJmDT6voN738A2arTdiDt8koexTBt05VoWbDaNEWroL0tIE37m5A== X-Received: by 10.36.48.23 with SMTP id q23mr13694317itq.6.1486499528814; Tue, 07 Feb 2017 12:32:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.36.41.145 with HTTP; Tue, 7 Feb 2017 12:32:08 -0800 (PST) In-Reply-To: <20170207201253.4i2ye6inqwma65rf@macpro.local> References: <20170123213728.89900-1-luc.vanoostenryck@gmail.com> <20170123213728.89900-3-luc.vanoostenryck@gmail.com> <20170207201253.4i2ye6inqwma65rf@macpro.local> From: Christopher Li Date: Wed, 8 Feb 2017 04:32:08 +0800 X-Google-Sender-Auth: WyuVe7zXE8CBLATWk7xNh4tDfMo Message-ID: Subject: Re: [PATCH 2/3] allow builtins to have prototype and evaluate/expand methods To: Luc Van Oostenryck Cc: Linux-Sparse Sender: linux-sparse-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-sparse@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Wed, Feb 8, 2017 at 4:12 AM, Luc Van Oostenryck wrote: > > I'm very well aware of this bug/problem, it creates all sort of complications > but I vaguely understood it was a design choice. To be 100%, you're talking > the fact that each declaration create a new symbol only related by their > identifier chain, right? Yes. I don't see a way not creating the symbol for each declaration. However, we can make a better job at migrating the bits between each declaration. > > Yes and diagnose any compatibility. > I'll give it a try but I won't be able to do that before the weekend. No problem. Just in case you miss it. I attach a one line patch in my previous email. I attach it here again. Chris --- sparse.chrisl.orig/parse.c +++ sparse.chrisl/parse.c @@ -2879,8 +2879,10 @@ struct token *external_declaration(struc } } check_declaration(decl); - if (decl->same_symbol) + if (decl->same_symbol) { decl->definition = decl->same_symbol->definition; + decl->op = decl->same_symbol->op; + } if (!match_op(token, ',')) break;