fix: Replaced MATCHED_VAR in logdata argument by a real target name #3543
Conversation
Sorry, what "same issue" do you think? Is there any other issue that affects? |
|
Consider this: Why does this work for |
|
This workaround has been first introduced with #2347. I think that So, to the best of my understanding, It should be something to always look at when relying on this workaround. For example, looking at |
|
Ah, thanks!
I think this is because of the engines behavior. @M4tteoP explained here the reason, I can add only my notes regarding this:
that So we can try to use this variable, but even though we started using this kind of workaround, I think it would be better to use it consistently. I just wanted to fix that issue before the release. And may be we (I) should add the check against this behavior to crs-rules-check. I don't know if it would have any effect to release or not. |
|
@airween I'm sure you checked that the workaround works for you, so I'll merge now. However, I believe it would be good to check for the use of these variables in conjunction with chain rules and to require that the workaround is being applied. |
I didn't check but I found a rule which used that, namely 942440. In that case this behavior did not appear, I checked that. Anyway, we started to use this type of solution, so I suggest we keep on this way. |
This PR fixes the listed behaviors under issue #3428. The solution is similar like in case of #3409.
changelog comment:
fix: Added missing target name to logdata (942521 PL2, 943110 PL1, 943120 PL1) (Ervin Hegedüs)
Fixes #3428