xref: /freebsd/contrib/bmake/unit-tests/opt-debug-lint.mk (revision 759b177aecbfc49ebc900739954ac56b1aa5fc53)
1*759b177aSSimon J. Gerraty# $NetBSD: opt-debug-lint.mk,v 1.24 2025/04/04 18:57:01 rillig Exp $
2956e45f6SSimon J. Gerraty#
3956e45f6SSimon J. Gerraty# Tests for the -dL command line option, which runs additional checks
4d5e0a182SSimon J. Gerraty# to catch common mistakes, such as unclosed 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
19148ee845SSimon J. Gerraty# expect+1: Variable "X" is undefined
20956e45f6SSimon J. Gerraty.if $X
21956e45f6SSimon J. Gerraty.  error
22956e45f6SSimon J. Gerraty.endif
23956e45f6SSimon J. Gerraty
24956e45f6SSimon J. Gerraty# The dynamic variables like .TARGET are treated specially.  It does not make
25956e45f6SSimon J. Gerraty# sense to expand them in the global scope since they will never be defined
26956e45f6SSimon J. Gerraty# there under normal circumstances.  Therefore they expand to a string that
27956e45f6SSimon J. Gerraty# will later be expanded correctly, when the variable is evaluated again in
28956e45f6SSimon J. Gerraty# the scope of an actual target.
29956e45f6SSimon J. Gerraty#
30956e45f6SSimon J. Gerraty# Even though the "@" variable is not defined at this point, this is not an
31956e45f6SSimon J. Gerraty# error.  In all practical cases, this is no problem.  This particular test
32956e45f6SSimon J. Gerraty# case is made up and unrealistic.
33956e45f6SSimon J. Gerraty.if $@ != "\$(.TARGET)"
34956e45f6SSimon J. Gerraty.  error
35956e45f6SSimon J. Gerraty.endif
36956e45f6SSimon J. Gerraty
37956e45f6SSimon J. Gerraty# Since 2020-09-13, Var_Parse properly reports errors for undefined variables,
38956e45f6SSimon J. Gerraty# but only in lint mode.  Before, it had only silently returned var_Error,
39956e45f6SSimon J. Gerraty# hoping for the caller to print an error message.  This resulted in the
40956e45f6SSimon J. Gerraty# well-known "Malformed conditional" error message, even though the
41956e45f6SSimon J. Gerraty# conditional was well-formed and the only error was an undefined variable.
42148ee845SSimon J. Gerraty# expect+1: Variable "UNDEF" is undefined
43956e45f6SSimon J. Gerraty.if ${UNDEF}
44956e45f6SSimon J. Gerraty.  error
45956e45f6SSimon J. Gerraty.endif
46956e45f6SSimon J. Gerraty
47956e45f6SSimon J. Gerraty# Since 2020-09-14, dependency lines may contain undefined variables.
48956e45f6SSimon J. Gerraty# Before, undefined variables were forbidden, but this distinction was not
49956e45f6SSimon J. Gerraty# observable from the outside of the function Var_Parse.
50956e45f6SSimon J. Gerraty${UNDEF}: ${UNDEF}
51956e45f6SSimon J. Gerraty
52956e45f6SSimon J. Gerraty# In a condition that has a defined(UNDEF) guard, all guarded conditions
53956e45f6SSimon J. Gerraty# may assume that the variable is defined since they will only be evaluated
54956e45f6SSimon J. Gerraty# if the variable is indeed defined.  Otherwise they are only parsed, and
55956e45f6SSimon J. Gerraty# for parsing it doesn't make a difference whether the variable is defined
56956e45f6SSimon J. Gerraty# or not.
57956e45f6SSimon J. Gerraty.if defined(UNDEF) && exists(${UNDEF})
58956e45f6SSimon J. Gerraty.  error
59956e45f6SSimon J. Gerraty.endif
60956e45f6SSimon J. Gerraty
61956e45f6SSimon J. Gerraty# Since 2020-10-03, in lint mode the variable modifier must be separated
62956e45f6SSimon J. Gerraty# by colons.  See varparse-mod.mk.
636a7405f5SSimon J. Gerraty# expect+2: Missing delimiter ':' after modifier "L"
646a7405f5SSimon J. Gerraty# expect+1: Missing delimiter ':' after modifier "P"
65956e45f6SSimon J. Gerraty.if ${value:LPL} != "value"
66956e45f6SSimon J. Gerraty.  error
67956e45f6SSimon J. Gerraty.endif
68956e45f6SSimon J. Gerraty
6906b9b3e0SSimon J. Gerraty# Between 2020-10-03 and var.c 1.752 from 2020-12-20, in lint mode the
7006b9b3e0SSimon J. Gerraty# variable modifier had to be separated by colons.  This was wrong though
7106b9b3e0SSimon J. Gerraty# since make always fell back trying to parse the indirect modifier as a
7206b9b3e0SSimon J. Gerraty# SysV modifier.
73*759b177aSSimon J. Gerraty# expect+1: Unknown modifier ":${"
74*759b177aSSimon J. Gerraty.if ${value:${:UL}PL} != ""
75956e45f6SSimon J. Gerraty.  error ${value:${:UL}PL}
76*759b177aSSimon J. Gerraty.else
77*759b177aSSimon J. Gerraty.  error
78956e45f6SSimon J. Gerraty.endif
79956e45f6SSimon J. Gerraty
8006b9b3e0SSimon J. Gerraty# Typically, an indirect modifier is followed by a colon or the closing
8106b9b3e0SSimon J. Gerraty# brace.  This one isn't, therefore make falls back to parsing it as the SysV
8206b9b3e0SSimon J. Gerraty# modifier ":lue=lid".
8306b9b3e0SSimon J. Gerraty.if ${value:L:${:Ulue}=${:Ulid}} != "valid"
8406b9b3e0SSimon J. Gerraty.  error
8506b9b3e0SSimon J. Gerraty.endif
8606b9b3e0SSimon J. Gerraty
87b0c40a00SSimon J. Gerraty# In lint mode, the whole variable text is evaluated to check for unclosed
88b0c40a00SSimon J. Gerraty# expressions and unknown operators.  During this check, the subexpression
89b0c40a00SSimon J. Gerraty# '${:U2}' is not expanded, instead it is copied verbatim into the regular
90b0c40a00SSimon J. Gerraty# expression, leading to '.*=.{1,${:U2}}$'.
91b0c40a00SSimon J. Gerraty#
92b0c40a00SSimon J. Gerraty# Before var.c 1.856 from 2021-03-14, this regular expression was then
93b0c40a00SSimon J. Gerraty# compiled even though that was not necessary for checking the syntax at the
94d5e0a182SSimon J. Gerraty# level of expressions.  The unexpanded '$' then resulted in a wrong
95b0c40a00SSimon J. Gerraty# error message.
96b0c40a00SSimon J. Gerraty#
97b0c40a00SSimon J. Gerraty# This only happened in lint mode since in default mode the early check for
98b0c40a00SSimon J. Gerraty# unclosed expressions and unknown modifiers is skipped.
99b0c40a00SSimon J. Gerraty#
100b0c40a00SSimon J. Gerraty# See VarCheckSyntax, ApplyModifier_Regex.
101b0c40a00SSimon J. Gerraty#
102b0c40a00SSimon J. GerratyVARMOD_REGEX=	${:UA=111 B=222 C=33:C/.*=.{1,${:U2}}$//g}
103