1*06b9b3e0SSimon J. Gerraty# $NetBSD: opt-debug-lint.mk,v 1.12 2020/12/20 19:10:53 rillig Exp $ 2956e45f6SSimon J. Gerraty# 3956e45f6SSimon J. Gerraty# Tests for the -dL command line option, which runs additional checks 4956e45f6SSimon J. Gerraty# to catch common mistakes, such as unclosed variable expressions. 5956e45f6SSimon J. Gerraty 6956e45f6SSimon J. Gerraty.MAKEFLAGS: -dL 7956e45f6SSimon J. Gerraty 8956e45f6SSimon J. Gerraty# Since 2020-09-13, undefined variables that are used on the left-hand side 9956e45f6SSimon J. Gerraty# of a condition at parse time get a proper error message. Before, the 10956e45f6SSimon J. Gerraty# error message was "Malformed conditional" only, which was wrong and 11956e45f6SSimon J. Gerraty# misleading. The form of the condition is totally fine, it's the evaluation 12956e45f6SSimon J. Gerraty# that fails. 13956e45f6SSimon J. Gerraty# 14956e45f6SSimon J. Gerraty# Since 2020-09-13, the "Malformed conditional" error message is not printed 15956e45f6SSimon J. Gerraty# anymore. 16956e45f6SSimon J. Gerraty# 17956e45f6SSimon J. Gerraty# See also: 18956e45f6SSimon J. Gerraty# cond-undef-lint.mk 19956e45f6SSimon J. Gerraty.if $X 20956e45f6SSimon J. Gerraty. error 21956e45f6SSimon J. Gerraty.endif 22956e45f6SSimon J. Gerraty 23956e45f6SSimon J. Gerraty# The dynamic variables like .TARGET are treated specially. It does not make 24956e45f6SSimon J. Gerraty# sense to expand them in the global scope since they will never be defined 25956e45f6SSimon J. Gerraty# there under normal circumstances. Therefore they expand to a string that 26956e45f6SSimon J. Gerraty# will later be expanded correctly, when the variable is evaluated again in 27956e45f6SSimon J. Gerraty# the scope of an actual target. 28956e45f6SSimon J. Gerraty# 29956e45f6SSimon J. Gerraty# Even though the "@" variable is not defined at this point, this is not an 30956e45f6SSimon J. Gerraty# error. In all practical cases, this is no problem. This particular test 31956e45f6SSimon J. Gerraty# case is made up and unrealistic. 32956e45f6SSimon J. Gerraty.if $@ != "\$(.TARGET)" 33956e45f6SSimon J. Gerraty. error 34956e45f6SSimon J. Gerraty.endif 35956e45f6SSimon J. Gerraty 36956e45f6SSimon J. Gerraty# Since 2020-09-13, Var_Parse properly reports errors for undefined variables, 37956e45f6SSimon J. Gerraty# but only in lint mode. Before, it had only silently returned var_Error, 38956e45f6SSimon J. Gerraty# hoping for the caller to print an error message. This resulted in the 39956e45f6SSimon J. Gerraty# well-known "Malformed conditional" error message, even though the 40956e45f6SSimon J. Gerraty# conditional was well-formed and the only error was an undefined variable. 41956e45f6SSimon J. Gerraty.if ${UNDEF} 42956e45f6SSimon J. Gerraty. error 43956e45f6SSimon J. Gerraty.endif 44956e45f6SSimon J. Gerraty 45956e45f6SSimon J. Gerraty# Since 2020-09-14, dependency lines may contain undefined variables. 46956e45f6SSimon J. Gerraty# Before, undefined variables were forbidden, but this distinction was not 47956e45f6SSimon J. Gerraty# observable from the outside of the function Var_Parse. 48956e45f6SSimon J. Gerraty${UNDEF}: ${UNDEF} 49956e45f6SSimon J. Gerraty 50956e45f6SSimon J. Gerraty# In a condition that has a defined(UNDEF) guard, all guarded conditions 51956e45f6SSimon J. Gerraty# may assume that the variable is defined since they will only be evaluated 52956e45f6SSimon J. Gerraty# if the variable is indeed defined. Otherwise they are only parsed, and 53956e45f6SSimon J. Gerraty# for parsing it doesn't make a difference whether the variable is defined 54956e45f6SSimon J. Gerraty# or not. 55956e45f6SSimon J. Gerraty.if defined(UNDEF) && exists(${UNDEF}) 56956e45f6SSimon J. Gerraty. error 57956e45f6SSimon J. Gerraty.endif 58956e45f6SSimon J. Gerraty 59956e45f6SSimon J. Gerraty# Since 2020-10-03, in lint mode the variable modifier must be separated 60956e45f6SSimon J. Gerraty# by colons. See varparse-mod.mk. 61956e45f6SSimon J. Gerraty.if ${value:LPL} != "value" 62956e45f6SSimon J. Gerraty. error 63956e45f6SSimon J. Gerraty.endif 64956e45f6SSimon J. Gerraty 65*06b9b3e0SSimon J. Gerraty# Between 2020-10-03 and var.c 1.752 from 2020-12-20, in lint mode the 66*06b9b3e0SSimon J. Gerraty# variable modifier had to be separated by colons. This was wrong though 67*06b9b3e0SSimon J. Gerraty# since make always fell back trying to parse the indirect modifier as a 68*06b9b3e0SSimon J. Gerraty# SysV modifier. 69956e45f6SSimon J. Gerraty.if ${value:${:UL}PL} != "LPL}" # FIXME: "LPL}" is unexpected here. 70956e45f6SSimon J. Gerraty. error ${value:${:UL}PL} 71956e45f6SSimon J. Gerraty.endif 72956e45f6SSimon J. Gerraty 73*06b9b3e0SSimon J. Gerraty# Typically, an indirect modifier is followed by a colon or the closing 74*06b9b3e0SSimon J. Gerraty# brace. This one isn't, therefore make falls back to parsing it as the SysV 75*06b9b3e0SSimon J. Gerraty# modifier ":lue=lid". 76*06b9b3e0SSimon J. Gerraty.if ${value:L:${:Ulue}=${:Ulid}} != "valid" 77*06b9b3e0SSimon J. Gerraty. error 78*06b9b3e0SSimon J. Gerraty.endif 79*06b9b3e0SSimon J. Gerraty 80956e45f6SSimon J. Gerratyall: 81956e45f6SSimon J. Gerraty @:; 82