---
- branch: MAIN
  date: Wed Sep  2 05:33:58 UTC 2020
  files:
  - new: '1.915'
    old: '1.914'
    path: src/distrib/sets/lists/tests/mi
    pathrev: src/distrib/sets/lists/tests/mi@1.915
    type: modified
  - new: '1.130'
    old: '1.129'
    path: src/usr.bin/make/unit-tests/Makefile
    pathrev: src/usr.bin/make/unit-tests/Makefile@1.130
    type: modified
  - new: '1.1'
    old: '0'
    path: src/usr.bin/make/unit-tests/directive-for.exp
    pathrev: src/usr.bin/make/unit-tests/directive-for.exp@1.1
    type: added
  - new: '1.1'
    old: '0'
    path: src/usr.bin/make/unit-tests/directive-for.mk
    pathrev: src/usr.bin/make/unit-tests/directive-for.mk@1.1
    type: added
  id: 20200902T053358Z.ed97e93f709dbb9427089aaf23ea72b647d86882
  log: |
    make(1): add test for the .for directive

    For a long time, I had assumed that the iteration variables of a .for
    loop are just normal global variables.  This assumption was wrong but
    didn't have any consequences.

    The iteration variables of a .for loop can just be accessed like global
    variables, therefore it is not obvious that they are implemented in a
    completely different way.

    There are some edge cases in conditions used inside .for loops, in which
    the iteration variables cannot be used like normal variables.  An
    example is brought up in https://gnats.netbsd.org/47888, which observes
    that the defined() and empty() functions in conditions only work with
    variables but ignore the iteration "variables", simply because these are
    not variables but only expressions.
  module: src
  subject: 'CVS commit: src'
  unixtime: '1599024838'
  user: rillig