playstation-edd wrote: > Just to check my understanding, things like CHECK-MAIN-CRT-SAME are going to > shift the match-position that FileCheck is looking at forwards, so that we > have to match in the correct order, yes?
Yep! > I get the feeling that given how much of the construct-a-job logic filters > for `!Relocatable` it might be worth having that as an early exit. On the > other hand, the logic here is already a complicated matrix of expectations, > no need to make it more complicated in the name of lines-of-code. There's are bits of `Relocatable`-agnostic stuff in the middle (`AddLinkerInputs()`) and at the end, so I don't know how much tidier or smaller it can be made. I'm don't find it's current state especially offensive, but I could have a go at moving the new stuff to some helper functions, perhaps? > For the CHECK-NO... flavour of checklines, would they be better as > `--check-implicit-not` arguments to FileCheck, or is it alright to rely on > them being in a rigid order? (No strong opinion). Thanks - `--check-implicit-not` would indeed be better from a strictness point of view. So I have pushed this change for your consideration. After doing it, I'm not so sure it's overall better, as the regular expressions are now repeated in a number of places and I have had to carefully quote them so that lit's command parser doesn't e.g. interpret `*` as glob, and instead leaves it for `FileCheck` to interpret as a part of a regex. I have a very slight preference to revert this particular commit as I feel there's slightly more chance for error now, though I did validate with some experiments. Let me know what you think. https://github.com/llvm/llvm-project/pull/115497 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
