Remove noisy log from startup #35954
Conversation
| FML_LOG(INFO) << "populate_existing_damage was not defined, disabling " | ||
| "partial repaint. If you wish to enable partial repaint, " | ||
| "please define this callback."; | ||
| } |
There was a problem hiding this comment.
The embedder API has lots of other optional callbacks that no-op if they aren't provided. The embedder API does not log a message if those other optional callbacks aren't provided.
|
@cbracken I think we should cherry pick this, however, the Flutter Windows integration tests were added after the 3.3 branch was cut. I suppose I can cherry pick just the fix without the test. Do you have any concerns with that? |
| std::string cout = cout_buffer.str(); | ||
| std::string cerr = cerr_buffer.str(); | ||
| EXPECT_TRUE(cout.empty()); | ||
| EXPECT_TRUE(cerr.empty()); |
There was a problem hiding this comment.
You can use testing::internal::CaptureStdout() and testing::internal::GetCapturedStdout() to make this more succinct and avoid the possibility of copy/paste and forgetting to restore at the end.
There was a problem hiding this comment.
I considered this but then found this message by the gtest folks: https://groups.google.com/g/googletestframework/c/7OTybZo-jp8
First of all, you should not use APIs marked as "internal".
They are not part of the public API, are not supported and are subject to change at any time.
And:
No, those APIs are internal for testing gTest itself.
They do so by overriding the stdout/stderr file descriptors and forwarding the data into a file, which means that they interfere with the actual output of the binary.
They could forward the output to the actual stdout/err, but that is more complex and there is no reason to do so on these internal APIs.It is rather trivial to capture std::cout/std::cerr (not stdout/stderr) on your side, if you want.
Eg: http://stackoverflow.com/questions/5419356/redirect-stdout-stderr-to-a-string
I think if this becomes a common pattern we could introduce a helper to prevent possible gotchas.
There was a problem hiding this comment.
I accidentally added the autosubmit to this before letting you reply. Let me know if you have feedback, I'd be happy to send a follow-up pull request. Sorry about that!
There was a problem hiding this comment.
Seems reasonable. If we find ourselves needing to do this more than once we should create an RAII wrapper that does the grabbing and restoring.
This is a super low-risk fix. What is the impact? End-users aren't going to be seeing console logging, so I assume it affects developers only, and that it's visible even without the --verbose setting due to the timing? This is pretty borderline for a cherry-pick. There's no crash or end-user-visible bug -- i.e. it doesn't affect flutter app users, just developers. It's a single log message to the console at startup. I'd expect the primary impacts are:
I agree it's a very low-risk cherry-pick, but I don't think it qualifies for widespread serious user impact unless I'm misunderstanding the impact. |
|
Yup that impact is exactly right: it just affects developers. Given that, I'll skip the cherry pick! :) |
This removes a noisy log from the startup path. Normally INFO logs are skipped by default, however, this particular log is sent before the verbosity level has been set.
This also adds a test to verify that a default Flutter Windows app does not output anything to stdout or stderr.
/cc @betrevisan
Fixes flutter/flutter#110231
Pre-launch Checklist
writing and running engine tests.
///).If you need help, consider asking for advice on the #hackers-new channel on Discord.