Is there a way to allow for an unmatched 'package()' filter in a config file?

[smalis-msft]

I have a bit of an odd situation and would like some advice on the best way to fix things. I work in a single git repo with two rust workspaces, where the contents of one are allowed to depend on the other, but not vice-versa. Let's call them the super-workspace and the sub-workspace respectively. For the sake of convenience we've been sharing a single nextest config file between them, and this has worked fine for a while. However recently I tried to add an override for a package in the sub-workspace, and started hitting errors when trying to use this config file in the super-workspace, as the package does not exist there. Basically I have this:

[[profile.default.overrides]]
# this causes an "error: operator didn't match any packages" in the super-workspace
filter = 'package(sub_workspace_only)'
slow-timeout = { something }

[[profile.default.overrides]]
# however this causes no error, despite no tests matching in the super-workspace
filter = 'test(sub_workspace_only)'
slow-timeout = { something }

Is there some way I can make the former filter not cause an error when there are no matches? I understand it's useful to error out to catch potential typos and the like, but in my case the situation of 'no matching packages' is expected and allowable 50% of the time.

[sunshowers]

Interesting -- I think I'd be fine with an optional second argument to the package, deps and rdeps filtersets that squelches not-found errors within that context. Something like package(sub_workspace_only, missing=ignore). Would you like to work on this? Would require some parser changes.

[smalis-msft]

Well I think part of my question is "why does the test filter not error when there are no matches?" and "is there some way to make these match in behavior?"

I likely wouldn't have the time to work on whatever changes are needed unfortunately, and we've worked around the issue for now, but it is a bit of a papercut.

[sunshowers]

Well I think part of my question is "why does the test filter not error when there are no matches?"

The reason for that is the list of packages is known from static inspection of the Cargo metadata, but the list of tests is not known in advance (and can vary based on things like platforms and features). If the list of tests were known in advance I'd be inclined to make that filterset also reject test names that don't match anything by default.

"is there some way to make these match in behavior?"

Not by default, but the option I described would make them match in behavior.