Open Manishearth opened 2 years ago
+1 to logging, -1 to panicking based on a feature. We should condition on debug_assertions
and say we're panic-free in release mode.
Should the warnings be behind a feature? Should we route all the warnings through an intermediate crate like icu_provider?
Discuss with:
+1 behind a feature, am ambivalent about routing through icu_provider but I think that makes sense as a global toggle instead of adding features everywhere
log
crate is low overhead when you disable it, it's not completely free. I'm okay people depending on icu_provider for patterns like this. Maybe we should make icu_core which is the public API of cross things. But I think icu_provider is fine.serde
and std
, we could consider sync
and tracing
as more examples.@Manishearth proposal: the feature exists in 2 places: icu
and icu_provider
(or could be icu_core
). When you enable it, everyone in your dependency tree gets it.
serde
feature enables additional dependencies, so it's not the same thing.icu_provider/log_error_context
and just group it with the main feature?Conclusion:
icu/logging
, icu_provider/logging
, and icu_datagen/logging
logging
featurelog
crate, but we can upgrade it later, still using the same logging
feature nameLGTM: @sffc @Manishearth @robertbastian @skius @zbraniecki
icu_datagen
currently doesn't have a logging feature and logging is a pretty fundamental part of its behaviour. Logging can actually be turned off by not registering a logger, so I'm not sure we need a separate feature...
It would be nice if all ICU4X docs tests and unit tests would have logging enabled. Currently we have logs in the code to catch possibly-errorful conditions, but those logs are suppressed, making it difficult to debug (@atcupps).
Context: The use case is that if we don't recognize a calendar BCP-47 identifier, we fall back to the locale's default calendar, which is correct, expected logic, and we have a warning printed when this fallback occurs, but that warning is not being printed in unit tests.
We have a bunch of debug asserts that could probably be log::warn for better user experience.
Perhaps also have a
strict_assert
feature that switches between warning and panicking for testing purposes,.