linux-sparse.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
To: linux-sparse@vger.kernel.org
Cc: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Subject: [PATCH 11/17] scope: make function scope the same as the body block scope
Date: Mon, 13 Apr 2020 18:15:59 +0200	[thread overview]
Message-ID: <20200413161605.95900-12-luc.vanoostenryck@gmail.com> (raw)
In-Reply-To: <20200413161605.95900-1-luc.vanoostenryck@gmail.com>

Currently, the function scope (only used for labels) and
the block scope of the function's body are distinct scopes,
none being a child from the other.

This is fine as these scopes are currently unrelated but:
* it's unneeded and somehow unintuitive
* checking that gotos doesn't jump inside and expression
  statement is easier if these scopes are properly nested.

So, make the function scope and the body's block scope one
single scope.

Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
---
 scope.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/scope.c b/scope.c
index 0e4fb3b42150..175d72c23762 100644
--- a/scope.c
+++ b/scope.c
@@ -91,8 +91,8 @@ void start_symbol_scope(void)
 
 void start_function_scope(void)
 {
-	start_scope(&function_scope);
 	start_scope(&block_scope);
+	function_scope = block_scope;
 }
 
 static void remove_symbol_scope(struct symbol *sym)
@@ -137,7 +137,7 @@ void end_symbol_scope(void)
 void end_function_scope(void)
 {
 	end_scope(&block_scope);
-	end_scope(&function_scope);
+	function_scope = block_scope;
 }
 
 int is_outer_scope(struct scope *scope)
-- 
2.26.0

  parent reply	other threads:[~2020-04-13 16:16 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-13 16:15 [PATCH 00/17] detect invalid branches at evaluation time Luc Van Oostenryck
2020-04-13 16:15 ` [PATCH 01/17] bad-goto: add testcase for 'jump inside discarded expression statement' Luc Van Oostenryck
2020-04-13 16:15 ` [PATCH 02/17] bad-goto: add testcases for linearization of invalid labels Luc Van Oostenryck
2020-04-13 16:15 ` [PATCH 03/17] bad-goto: add more testcases Luc Van Oostenryck
2020-04-13 16:15 ` [PATCH 04/17] bad-goto: do not linearize if the IR will be invalid Luc Van Oostenryck
2020-04-13 16:15 ` [PATCH 05/17] bad-goto: reorg test in evaluate_goto_statement() Luc Van Oostenryck
2020-04-13 16:15 ` [PATCH 06/17] bad-goto: simplify testing of undeclared labels Luc Van Oostenryck
2020-04-13 16:15 ` [PATCH 07/17] bad-goto: do not linearize function with " Luc Van Oostenryck
2020-04-13 16:15 ` [PATCH 08/17] bad-goto: catch labels with reserved names Luc Van Oostenryck
2020-04-13 16:15 ` [PATCH 09/17] scope: no memset() needed after __alloc_scope() Luc Van Oostenryck
2020-04-13 16:15 ` [PATCH 10/17] scope: move scope opening/ending inside compound_statement() Luc Van Oostenryck
2020-04-13 16:15 ` Luc Van Oostenryck [this message]
2020-04-13 16:16 ` [PATCH 12/17] scope: s/{start,end}_symbol_scope/{start,end}_block_scope/ Luc Van Oostenryck
2020-04-13 16:16 ` [PATCH 13/17] scope: let labels have their own scope Luc Van Oostenryck
2020-04-13 17:30   ` Linus Torvalds
2020-04-13 16:16 ` [PATCH 14/17] scope: add is_in_scope() Luc Van Oostenryck
2020-04-13 16:16 ` [PATCH 15/17] scope: give a scope for labels & gotos Luc Van Oostenryck
2020-04-13 17:52   ` Linus Torvalds
2020-04-13 18:54     ` Luc Van Oostenryck
2020-04-13 19:32       ` Linus Torvalds
2020-04-13 20:00         ` Luc Van Oostenryck
2020-04-13 22:40         ` Linus Torvalds
2020-04-13 23:39           ` Luc Van Oostenryck
2020-04-14  7:49             ` Luc Van Oostenryck
2020-04-14 18:19               ` Linus Torvalds
2020-04-14 23:09                 ` Luc Van Oostenryck
2020-04-15  0:59                   ` Linus Torvalds
2020-05-14 22:22                     ` Luc Van Oostenryck
2020-04-13 16:16 ` [PATCH 16/17] bad-goto: catch gotos inside expression statements Luc Van Oostenryck
2020-04-13 16:16 ` [PATCH 17/17] bad-goto: cleanup evaluate_goto() Luc Van Oostenryck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200413161605.95900-12-luc.vanoostenryck@gmail.com \
    --to=luc.vanoostenryck@gmail.com \
    --cc=linux-sparse@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).