peek into file before open

[GitMensch]

• check file open, providing nice and early error
• explicit check for perfparser (magic number QPERFSTREAM) opening directly without the need to fall back to file name
• explicit check for V1 perf data which isn't supported by perfparser
• explicit check for unknown file type

Fixes: #477

[milianw]

one minor issue, otherwise lgtm

[milianw]

So should I capitalize Unknown?

yes, and the second message in the middle too. ideally, rephrase it to the more terse

Unsupported V1 perf data

[GitMensch]

I've started to add some tests. I can already use the tests/integrationtests/custom_cost_aggregation_testfiles/custom_cost_aggregation.perfparser file (use it both under its original name and copy it to a local file "fruitper" (opening works as expected in both cases), but I do miss a matching perf.data file.

Can you create and upload it (for later tests maybe multiple versions [with/without --call-graph + --sample-cpu])?

Do you have a PERFFILE (perf V1) anywhere [or even a Linux < 3.7 to create it]? I've only hex-edited a text-file, to trigger that message so far.

[GitMensch]

Requested changes done, PERFv1 and PERFv2 added, fixed opening of perf.data.gz (now also covered by the testsuite).
Is there more to do than handling the clazy waning (about now unused this as we use the decompressIfNeeded now outside of the lambda)?

[GitMensch]

lol, clang_lazy complains about QTRY_COMPARE_WITH_TIMEOUT (which is also used by QTRY_COMPARE, just with the default timeout 5000) to use QString::fromUtf8("QTestLib: This test case check (\"%1\") failed because the requested timeout (%2 ms) was too short, %3 ms would have been sufficient this time."); instead of QStringLiteral. The only option to solve that would to tinker with the QT macro or completely refrain from using it, ... or disable the Wclazy-qstring-allocations warning, which is possibly also doable for that single macro or at least function.

[milianw]

lol, clang_lazy complains about QTRY_COMPARE_WITH_TIMEOUT

odd bug, esp. considering we do -isystem /usr/include/qt - I'll investigate and potentially update clazy or so. we can ignore that for now - but there are two little nits I'd like to see fixed first please

[milianw]

Any idea why:

* the ubuntu-2204 test environment does not include perf?

we cannot run perf properly anyways inside the VM I believe, though maybe the task-clock backend is good enough for some basic testing. generally, it's a tricky one to get working in a portable fashion - I am not very fond of it anymore. it breaks every other day, when we update the compiler, elfutils or perf...

* the test, that is not run at all, SIGSEGVs?

what test, backtrace?

[GitMensch]

lol, clang_lazy complains about QTRY_COMPARE_WITH_TIMEOUT

odd bug, esp. considering we do -isystem /usr/include/qt

I agree.

I'll investigate and potentially update clazy or so. we can ignore that for now

Thanks.

but there are two little nits I'd like to see fixed first please

Which ones? While learning about QT and its _data test was quite interesting, I'd really like to get that out of my view soon :-)

[milianw]

but there are two little nits I'd like to see fixed first please

Which ones? While learning about QT and its _data test was quite interesting, I'd really like to get that out of my view soon :-)

Don't you see the two review comments of mine?

[milianw]

for some reasons these review changes didn't get published 🤷

[GitMensch]

@milianw Just a friendly ping - Is there anything open with this or the other PRs from my side?

[milianw]

OK, I removed one more usage of QString::isNull and added a patch to disable the clazy issues to get the CI green again - let's see if that's really the case then this can be merged

[milianw]

yep, lgtm now, I'll merge it - thanks for your contribution and patience with me :)