Closed dra27 closed 1 month ago
@kit-ty-kate rightly points out a timing issue which concretely invalidates one of the test cases. The filter above should repeat the guard of the dependency, i.e. instead of:
"--with-flexdll=%{flexdll:share}%" {flexdll:installed}
it should be:
"--with-flexdll=%{flexdll:share}%" {flexdll:installed & os = "win32"}
this also concretely rules out this line from the test:
["%{foo:share}%%{bar:share}%" {bar:installed}] {foo:installed}
since bar
is not referred to in the dependency formula in any way.
I'm wondering if this is in fact more related to #5928 - in order to use the variables, we need both that it's unequivocally guarded by :installed
(as here) and that the atom appears in some way in either depends
or depopt
(to enforce the ordering).
Regardless, the test case of bar
is a deficiency of this PR, so I'm putting it back to draft status for now.
Additional commit added which tweaks the check slightly. Now:
foo:share
still doesn't trigger warning 41 because it's guarded by foo:installed
and foo
is referred to in depends
bar:share
now triggers warning 41 because although it's guarded by bar:installed
, bar
is not referred to at all in depends
on depopts
baz:share
continues to trigger warning 41 because it's neither protected by bar:installed
nor referred to in depends
/depopts
:installed
variable if the package has not been referred to depends
/depopts
(which I think is better than the present behaviour of always allowing :installed
to be referred to, but that's open to further debate!)
The compiler packages contain the following snippet:
but the use of
flexdll:share
triggers lint warning 41 because the flexdll dependency is guarded byos
. However, this warning is a bit obtuse given the argument is guarded byflexdll:installed
(and:installed
explicitly doesn't trigger lint warning 41).This PR alters lint warning 41 so that when it evaluates the list of variables used in commands, it scans the filters for instances of
package:installed
and then performs a partial evaluation of the filter with thatpackage:installed
variable explicitly set to false (but nothing else set in the environment). If the filter reduces tofalse
, then all instances ofpackage:var
guarded by the filter are ignored.The first commit adds a test case showing the present behaviour, then the fix shows two of the packages warned being eliminated.