bug-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #59956] Recipes inside conditionals can break the parser


From: anonymous
Subject: [bug #59956] Recipes inside conditionals can break the parser
Date: Wed, 27 Jan 2021 15:29:02 -0500 (EST)
User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.141 Safari/537.36

URL:
  <https://savannah.gnu.org/bugs/?59956>

                 Summary: Recipes inside conditionals can break the parser 
                 Project: make
            Submitted by: None
            Submitted on: Wed 27 Jan 2021 08:29:00 PM UTC
                Severity: 3 - Normal
              Item Group: Bug
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
       Component Version: 4.3
        Operating System: Any
           Fixed Release: None
           Triage Status: None

    _______________________________________________________

Details:

I stumbled across a strange behavior and it's scary how trivial it appears. I
tested this with make 4.1, 4.2 and 4.3 on native Ubuntu 20.04, WSL-Ubuntu
18.04 and MSYS2.
Consider the following example:


ifeq (1,0)
test:
        @if [ "asd" == "123" ]; then
                echo "true"
        else
                echo "false"
        fi
endif


The *else* recipe at line 5 is treated as part of the *ifeq (1,0)* conditional
thus making the next recipe line fail because there is no target before it:


Makefile:6: *** recipe commences before first target.  Stop.
 

_I know the recipe does not make any sense without .ONESHELL, but it should
not matter. Maybe the user has a shell with a valid "else" command._
 
 
Adding *.ONESHELL:* above _(below does not work)_ fixes the problem. However,
if there is any other statement between *.ONESHELL:* and the conditional, this
causes the same problem.
This can be fixed by adding an additional .ONESHELL: just before the
conditional:


.ONESHELL: # Adding this line fixes the parser
aaa = 1    # Adding this line breaks the parser again
.ONESHELL: # Adding this line fixes the parser again

ifeq (1,0)
test:
        @if [ "asd" == "123" ]; then
                echo "true"
        else
                echo "false"
        fi
endif

 
If you can add a character immediately after the *else*, this does not happen
anymore:


SHELL = python3
.ONESHELL:

aaa = 1

ifeq (1,0)

test:
        @if 'a' == 'b':
          print('true')
        else: # No space between "else" and ":"
          print('false')

endif


Leaving a whitespace between *else* and *:* _(which is valid in python)_
brings the error back.

I found that changing *.RECIPEPREFIX:* also fixes the problem.

Is this really a bug or just some hidden intended behavior?




    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?59956>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]