Morph MORPH
SIGN IN SIGN UP
ziglang / zig UNCLAIMED

Moved to Codeberg

42798 0 0 Zig
Normal View History Raw
std.log: add documentation for scoped logging * Add short documentation to std.log.scoped and std.log.default * Update the module documentation and example to explain the difference between using explicit scopes, using a scoped logging namespace, and using the default namespace
2020-08-12 15:37:56 +02:00
//! std.log is a standardized interface for logging which allows for the logging
Introduce std.log std.log provides 8 log levels and corresponding logging functions. It allows the user to override the logging "backend" by defining root.log and to override the default log level by defining root.log_level. Logging functions accept a scope parameter which allows the implementer of the logging "backend" to filter logging by library as well as level. Using the standardized syslog [1] log levels ensures that std.log will be flexible enough to work for as many use-cases as possible. If we were to stick with only 3/4 log levels, std.log would be insufficient for large and/or complex projects such as a kernel or display server. [1]: https://tools.ietf.org/html/rfc5424#section-6.2.1
2020-05-15 17:10:56 +02:00
//! of programs and libraries using this interface to be formatted and filtered
std: collect all options under one namespace
2023-01-03 19:37:11 +02:00
//! by the implementer of the `std.options.logFn` function.
Introduce std.log std.log provides 8 log levels and corresponding logging functions. It allows the user to override the logging "backend" by defining root.log and to override the default log level by defining root.log_level. Logging functions accept a scope parameter which allows the implementer of the logging "backend" to filter logging by library as well as level. Using the standardized syslog [1] log levels ensures that std.log will be flexible enough to work for as many use-cases as possible. If we were to stick with only 3/4 log levels, std.log would be insufficient for large and/or complex projects such as a kernel or display server. [1]: https://tools.ietf.org/html/rfc5424#section-6.2.1
2020-05-15 17:10:56 +02:00
//!
std.log: update documentation and example for scoped logging
2020-08-13 17:12:16 +02:00
//! Each log message has an associated scope enum, which can be used to give
//! context to the logging. The logging functions in std.log implicitly use a
//! scope of .default.
//!
//! A logging namespace using a custom scope can be created using the
//! std.log.scoped function, passing the scope as an argument; the logging
//! functions in the resulting struct use the provided scope parameter.
//! For example, a library called 'libfoo' might use
//! `const log = std.log.scoped(.libfoo);` to use .libfoo as the scope of its
//! log messages.
Introduce std.log std.log provides 8 log levels and corresponding logging functions. It allows the user to override the logging "backend" by defining root.log and to override the default log level by defining root.log_level. Logging functions accept a scope parameter which allows the implementer of the logging "backend" to filter logging by library as well as level. Using the standardized syslog [1] log levels ensures that std.log will be flexible enough to work for as many use-cases as possible. If we were to stick with only 3/4 log levels, std.log would be insufficient for large and/or complex projects such as a kernel or display server. [1]: https://tools.ietf.org/html/rfc5424#section-6.2.1
2020-05-15 17:10:56 +02:00
//!
std: collect all options under one namespace
2023-01-03 19:37:11 +02:00
//! An example `logFn` might look something like this:
Introduce std.log std.log provides 8 log levels and corresponding logging functions. It allows the user to override the logging "backend" by defining root.log and to override the default log level by defining root.log_level. Logging functions accept a scope parameter which allows the implementer of the logging "backend" to filter logging by library as well as level. Using the standardized syslog [1] log levels ensures that std.log will be flexible enough to work for as many use-cases as possible. If we were to stick with only 3/4 log levels, std.log would be insufficient for large and/or complex projects such as a kernel or display server. [1]: https://tools.ietf.org/html/rfc5424#section-6.2.1
2020-05-15 17:10:56 +02:00
//!
//! ```
//! const std = @import("std");
//!
std.log: fix example
2025-05-22 12:50:33 +02:00
//! pub const std_options: std.Options = .{
std: collect all options under one namespace
2023-01-03 19:37:11 +02:00
//! // Set the log level to info
std: make options a struct instance instead of a namespace
2024-01-28 00:30:24 +02:00
//! .log_level = .info,
Introduce std.log std.log provides 8 log levels and corresponding logging functions. It allows the user to override the logging "backend" by defining root.log and to override the default log level by defining root.log_level. Logging functions accept a scope parameter which allows the implementer of the logging "backend" to filter logging by library as well as level. Using the standardized syslog [1] log levels ensures that std.log will be flexible enough to work for as many use-cases as possible. If we were to stick with only 3/4 log levels, std.log would be insufficient for large and/or complex projects such as a kernel or display server. [1]: https://tools.ietf.org/html/rfc5424#section-6.2.1
2020-05-15 17:10:56 +02:00
//!
std: collect all options under one namespace
2023-01-03 19:37:11 +02:00
//! // Define logFn to override the std implementation
std: make options a struct instance instead of a namespace
2024-01-28 00:30:24 +02:00
//! .logFn = myLogFn,
std: collect all options under one namespace
2023-01-03 19:37:11 +02:00
//! };
//!
//! pub fn myLogFn(
Introduce std.log std.log provides 8 log levels and corresponding logging functions. It allows the user to override the logging "backend" by defining root.log and to override the default log level by defining root.log_level. Logging functions accept a scope parameter which allows the implementer of the logging "backend" to filter logging by library as well as level. Using the standardized syslog [1] log levels ensures that std.log will be flexible enough to work for as many use-cases as possible. If we were to stick with only 3/4 log levels, std.log would be insufficient for large and/or complex projects such as a kernel or display server. [1]: https://tools.ietf.org/html/rfc5424#section-6.2.1
2020-05-15 17:10:56 +02:00
//! comptime level: std.log.Level,
std: update `std.builtin.Type` fields to follow naming conventions The compiler actually doesn't need any functional changes for this: Sema does reification based on the tag indices of `std.builtin.Type` already! So, no zig1.wasm update is necessary. This change is necessary to disallow name clashes between fields and decls on a type, which is a prerequisite of #9938.
2024-08-28 02:35:53 +01:00
//! comptime scope: @Type(.enum_literal),
Introduce std.log std.log provides 8 log levels and corresponding logging functions. It allows the user to override the logging "backend" by defining root.log and to override the default log level by defining root.log_level. Logging functions accept a scope parameter which allows the implementer of the logging "backend" to filter logging by library as well as level. Using the standardized syslog [1] log levels ensures that std.log will be flexible enough to work for as many use-cases as possible. If we were to stick with only 3/4 log levels, std.log would be insufficient for large and/or complex projects such as a kernel or display server. [1]: https://tools.ietf.org/html/rfc5424#section-6.2.1
2020-05-15 17:10:56 +02:00
//! comptime format: []const u8,
update compile error tests and some doc comments
2020-07-11 22:04:38 +03:00
//! args: anytype,
Introduce std.log std.log provides 8 log levels and corresponding logging functions. It allows the user to override the logging "backend" by defining root.log and to override the default log level by defining root.log_level. Logging functions accept a scope parameter which allows the implementer of the logging "backend" to filter logging by library as well as level. Using the standardized syslog [1] log levels ensures that std.log will be flexible enough to work for as many use-cases as possible. If we were to stick with only 3/4 log levels, std.log would be insufficient for large and/or complex projects such as a kernel or display server. [1]: https://tools.ietf.org/html/rfc5424#section-6.2.1
2020-05-15 17:10:56 +02:00
//! ) void {
std.log: simplify to 4 distinct log levels Over the last year of using std.log in practice, it has become clear to me that having the current 8 distinct log levels does more harm than good. It is too subjective which level a given message should have which makes filtering based on log level weaker as not all messages will have been assigned the log level one might expect. Instead, more granular filtering should be achieved by leveraging the logging scope feature. Filtering based on a combination of scope and log level should be sufficiently powerful for all use-cases. Note that the self hosted compiler has already limited itself to 4 distinct log levels for many months and implemented granular filtering based on both log scope and level. This has worked very well in practice while working on the self hosted compiler.
2021-10-24 13:13:06 +02:00
//! // Ignore all non-error logging from sources other than
std.log: add functionality to check if a specific log level and scope are enabled
2022-10-26 21:03:02 +01:00
//! // .my_project, .nice_library and the default
Introduce std.log std.log provides 8 log levels and corresponding logging functions. It allows the user to override the logging "backend" by defining root.log and to override the default log level by defining root.log_level. Logging functions accept a scope parameter which allows the implementer of the logging "backend" to filter logging by library as well as level. Using the standardized syslog [1] log levels ensures that std.log will be flexible enough to work for as many use-cases as possible. If we were to stick with only 3/4 log levels, std.log would be insufficient for large and/or complex projects such as a kernel or display server. [1]: https://tools.ietf.org/html/rfc5424#section-6.2.1
2020-05-15 17:10:56 +02:00
//! const scope_prefix = "(" ++ switch (scope) {
std.log: add functionality to check if a specific log level and scope are enabled
2022-10-26 21:03:02 +01:00
//! .my_project, .nice_library, std.log.default_log_scope => @tagName(scope),
all: zig fmt and rename "@XToY" to "@YFromX" Signed-off-by: Eric Joldasov <bratishkaerik@getgoogleoff.me>
2023-06-15 13:14:16 +06:00
//! else => if (@intFromEnum(level) <= @intFromEnum(std.log.Level.err))
Introduce std.log std.log provides 8 log levels and corresponding logging functions. It allows the user to override the logging "backend" by defining root.log and to override the default log level by defining root.log_level. Logging functions accept a scope parameter which allows the implementer of the logging "backend" to filter logging by library as well as level. Using the standardized syslog [1] log levels ensures that std.log will be flexible enough to work for as many use-cases as possible. If we were to stick with only 3/4 log levels, std.log would be insufficient for large and/or complex projects such as a kernel or display server. [1]: https://tools.ietf.org/html/rfc5424#section-6.2.1
2020-05-15 17:10:56 +02:00
//! @tagName(scope)
//! else
//! return,
//! } ++ "): ";
//!
Using `comptime level.asText()` in log example Some recent change makes slice concatenation runtime (merge #12368), so the example needs to be explicitly made comptime.
2022-08-30 18:07:23 -03:00
//! const prefix = "[" ++ comptime level.asText() ++ "] " ++ scope_prefix;
Introduce std.log std.log provides 8 log levels and corresponding logging functions. It allows the user to override the logging "backend" by defining root.log and to override the default log level by defining root.log_level. Logging functions accept a scope parameter which allows the implementer of the logging "backend" to filter logging by library as well as level. Using the standardized syslog [1] log levels ensures that std.log will be flexible enough to work for as many use-cases as possible. If we were to stick with only 3/4 log levels, std.log would be insufficient for large and/or complex projects such as a kernel or display server. [1]: https://tools.ietf.org/html/rfc5424#section-6.2.1
2020-05-15 17:10:56 +02:00
//!
//! // Print the message to stderr, silently ignoring any errors
update the codebase for the new std.Progress API
2024-05-24 08:22:47 -07:00
//! std.debug.lockStdErr();
//! defer std.debug.unlockStdErr();
std.fmt: breaking API changes added adapter to AnyWriter and GenericWriter to help bridge the gap between old and new API make std.testing.expectFmt work at compile-time std.fmt no longer has a dependency on std.unicode. Formatted printing was never properly unicode-aware. Now it no longer pretends to be. Breakage/deprecations: * std.fs.File.reader -> std.fs.File.deprecatedReader * std.fs.File.writer -> std.fs.File.deprecatedWriter * std.io.GenericReader -> std.io.Reader * std.io.GenericWriter -> std.io.Writer * std.io.AnyReader -> std.io.Reader * std.io.AnyWriter -> std.io.Writer * std.fmt.format -> std.fmt.deprecatedFormat * std.fmt.fmtSliceEscapeLower -> std.ascii.hexEscape * std.fmt.fmtSliceEscapeUpper -> std.ascii.hexEscape * std.fmt.fmtSliceHexLower -> {x} * std.fmt.fmtSliceHexUpper -> {X} * std.fmt.fmtIntSizeDec -> {B} * std.fmt.fmtIntSizeBin -> {Bi} * std.fmt.fmtDuration -> {D} * std.fmt.fmtDurationSigned -> {D} * {} -> {f} when there is a format method * format method signature - anytype -> *std.io.Writer - inferred error set -> error{WriteFailed} - options -> (deleted) * std.fmt.Formatted - now takes context type explicitly - no fmt string
2025-06-27 20:05:22 -07:00
//! const stderr = std.fs.File.stderr().deprecatedWriter();
Fix std.log example to make the log handler print the newline Follow up from #5910
2020-07-22 23:26:41 +02:00
//! nosuspend stderr.print(prefix ++ format ++ "\n", args) catch return;
Introduce std.log std.log provides 8 log levels and corresponding logging functions. It allows the user to override the logging "backend" by defining root.log and to override the default log level by defining root.log_level. Logging functions accept a scope parameter which allows the implementer of the logging "backend" to filter logging by library as well as level. Using the standardized syslog [1] log levels ensures that std.log will be flexible enough to work for as many use-cases as possible. If we were to stick with only 3/4 log levels, std.log would be insufficient for large and/or complex projects such as a kernel or display server. [1]: https://tools.ietf.org/html/rfc5424#section-6.2.1
2020-05-15 17:10:56 +02:00
//! }
//!
//! pub fn main() void {
std.log: update documentation and example for scoped logging
2020-08-13 17:12:16 +02:00
//! // Using the default scope:
std.log: simplify to 4 distinct log levels Over the last year of using std.log in practice, it has become clear to me that having the current 8 distinct log levels does more harm than good. It is too subjective which level a given message should have which makes filtering based on log level weaker as not all messages will have been assigned the log level one might expect. Instead, more granular filtering should be achieved by leveraging the logging scope feature. Filtering based on a combination of scope and log level should be sufficiently powerful for all use-cases. Note that the self hosted compiler has already limited itself to 4 distinct log levels for many months and implemented granular filtering based on both log scope and level. This has worked very well in practice while working on the self hosted compiler.
2021-10-24 13:13:06 +02:00
//! std.log.debug("A borderline useless debug log message", .{}); // Won't be printed as log_level is .info
//! std.log.info("Flux capacitor is starting to overheat", .{});
std.log: add documentation for scoped logging * Add short documentation to std.log.scoped and std.log.default * Update the module documentation and example to explain the difference between using explicit scopes, using a scoped logging namespace, and using the default namespace
2020-08-12 15:37:56 +02:00
//!
std.log: update documentation and example for scoped logging
2020-08-13 17:12:16 +02:00
//! // Using scoped logging:
//! const my_project_log = std.log.scoped(.my_project);
//! const nice_library_log = std.log.scoped(.nice_library);
//! const verbose_lib_log = std.log.scoped(.verbose_lib);
std.log: add documentation for scoped logging * Add short documentation to std.log.scoped and std.log.default * Update the module documentation and example to explain the difference between using explicit scopes, using a scoped logging namespace, and using the default namespace
2020-08-12 15:37:56 +02:00
//!
std.log: simplify to 4 distinct log levels Over the last year of using std.log in practice, it has become clear to me that having the current 8 distinct log levels does more harm than good. It is too subjective which level a given message should have which makes filtering based on log level weaker as not all messages will have been assigned the log level one might expect. Instead, more granular filtering should be achieved by leveraging the logging scope feature. Filtering based on a combination of scope and log level should be sufficiently powerful for all use-cases. Note that the self hosted compiler has already limited itself to 4 distinct log levels for many months and implemented granular filtering based on both log scope and level. This has worked very well in practice while working on the self hosted compiler.
2021-10-24 13:13:06 +02:00
//! my_project_log.debug("Starting up", .{}); // Won't be printed as log_level is .info
//! nice_library_log.warn("Something went very wrong, sorry", .{});
//! verbose_lib_log.warn("Added 1 + 1: {}", .{1 + 1}); // Won't be printed as it gets filtered out by our log function
Introduce std.log std.log provides 8 log levels and corresponding logging functions. It allows the user to override the logging "backend" by defining root.log and to override the default log level by defining root.log_level. Logging functions accept a scope parameter which allows the implementer of the logging "backend" to filter logging by library as well as level. Using the standardized syslog [1] log levels ensures that std.log will be flexible enough to work for as many use-cases as possible. If we were to stick with only 3/4 log levels, std.log would be insufficient for large and/or complex projects such as a kernel or display server. [1]: https://tools.ietf.org/html/rfc5424#section-6.2.1
2020-05-15 17:10:56 +02:00
//! }
//! ```
//! Which produces the following output:
//! ```
std.log: simplify to 4 distinct log levels Over the last year of using std.log in practice, it has become clear to me that having the current 8 distinct log levels does more harm than good. It is too subjective which level a given message should have which makes filtering based on log level weaker as not all messages will have been assigned the log level one might expect. Instead, more granular filtering should be achieved by leveraging the logging scope feature. Filtering based on a combination of scope and log level should be sufficiently powerful for all use-cases. Note that the self hosted compiler has already limited itself to 4 distinct log levels for many months and implemented granular filtering based on both log scope and level. This has worked very well in practice while working on the self hosted compiler.
2021-10-24 13:13:06 +02:00
//! [info] (default): Flux capacitor is starting to overheat
//! [warning] (nice_library): Something went very wrong, sorry
Introduce std.log std.log provides 8 log levels and corresponding logging functions. It allows the user to override the logging "backend" by defining root.log and to override the default log level by defining root.log_level. Logging functions accept a scope parameter which allows the implementer of the logging "backend" to filter logging by library as well as level. Using the standardized syslog [1] log levels ensures that std.log will be flexible enough to work for as many use-cases as possible. If we were to stick with only 3/4 log levels, std.log would be insufficient for large and/or complex projects such as a kernel or display server. [1]: https://tools.ietf.org/html/rfc5424#section-6.2.1
2020-05-15 17:10:56 +02:00
//! ```
zig fmt the std lib
2021-02-24 21:29:01 -07:00
const std = @import("std.zig");
migrate from `std.Target.current` to `@import("builtin").target` closes #9388 closes #9321
2021-10-04 23:47:27 -07:00
const builtin = @import("builtin");
zig fmt the std lib
2021-02-24 21:29:01 -07:00
Introduce std.log std.log provides 8 log levels and corresponding logging functions. It allows the user to override the logging "backend" by defining root.log and to override the default log level by defining root.log_level. Logging functions accept a scope parameter which allows the implementer of the logging "backend" to filter logging by library as well as level. Using the standardized syslog [1] log levels ensures that std.log will be flexible enough to work for as many use-cases as possible. If we were to stick with only 3/4 log levels, std.log would be insufficient for large and/or complex projects such as a kernel or display server. [1]: https://tools.ietf.org/html/rfc5424#section-6.2.1
2020-05-15 17:10:56 +02:00
pub const Level = enum {
std.log: simplify to 4 distinct log levels Over the last year of using std.log in practice, it has become clear to me that having the current 8 distinct log levels does more harm than good. It is too subjective which level a given message should have which makes filtering based on log level weaker as not all messages will have been assigned the log level one might expect. Instead, more granular filtering should be achieved by leveraging the logging scope feature. Filtering based on a combination of scope and log level should be sufficiently powerful for all use-cases. Note that the self hosted compiler has already limited itself to 4 distinct log levels for many months and implemented granular filtering based on both log scope and level. This has worked very well in practice while working on the self hosted compiler.
2021-10-24 13:13:06 +02:00
/// Error: something has gone wrong. This might be recoverable or might
/// be followed by the program exiting.
Introduce std.log std.log provides 8 log levels and corresponding logging functions. It allows the user to override the logging "backend" by defining root.log and to override the default log level by defining root.log_level. Logging functions accept a scope parameter which allows the implementer of the logging "backend" to filter logging by library as well as level. Using the standardized syslog [1] log levels ensures that std.log will be flexible enough to work for as many use-cases as possible. If we were to stick with only 3/4 log levels, std.log would be insufficient for large and/or complex projects such as a kernel or display server. [1]: https://tools.ietf.org/html/rfc5424#section-6.2.1
2020-05-15 17:10:56 +02:00
err,
/// Warning: it is uncertain if something has gone wrong or not, but the
/// circumstances would be worth investigating.
warn,
std.log: simplify to 4 distinct log levels Over the last year of using std.log in practice, it has become clear to me that having the current 8 distinct log levels does more harm than good. It is too subjective which level a given message should have which makes filtering based on log level weaker as not all messages will have been assigned the log level one might expect. Instead, more granular filtering should be achieved by leveraging the logging scope feature. Filtering based on a combination of scope and log level should be sufficiently powerful for all use-cases. Note that the self hosted compiler has already limited itself to 4 distinct log levels for many months and implemented granular filtering based on both log scope and level. This has worked very well in practice while working on the self hosted compiler.
2021-10-24 13:13:06 +02:00
/// Info: general messages about the state of the program.
Introduce std.log std.log provides 8 log levels and corresponding logging functions. It allows the user to override the logging "backend" by defining root.log and to override the default log level by defining root.log_level. Logging functions accept a scope parameter which allows the implementer of the logging "backend" to filter logging by library as well as level. Using the standardized syslog [1] log levels ensures that std.log will be flexible enough to work for as many use-cases as possible. If we were to stick with only 3/4 log levels, std.log would be insufficient for large and/or complex projects such as a kernel or display server. [1]: https://tools.ietf.org/html/rfc5424#section-6.2.1
2020-05-15 17:10:56 +02:00
info,
/// Debug: messages only useful for debugging.
debug,
Expose mechanism to convert log level to text
2021-06-24 04:30:05 -06:00
/// Returns a string literal of the given level in full text form.
`std.log`: deduplicate `switch`
2022-07-06 19:27:47 +02:00
pub fn asText(comptime self: Level) []const u8 {
Expose mechanism to convert log level to text
2021-06-24 04:30:05 -06:00
return switch (self) {
.err => "error",
.warn => "warning",
std.log: simplify to 4 distinct log levels Over the last year of using std.log in practice, it has become clear to me that having the current 8 distinct log levels does more harm than good. It is too subjective which level a given message should have which makes filtering based on log level weaker as not all messages will have been assigned the log level one might expect. Instead, more granular filtering should be achieved by leveraging the logging scope feature. Filtering based on a combination of scope and log level should be sufficiently powerful for all use-cases. Note that the self hosted compiler has already limited itself to 4 distinct log levels for many months and implemented granular filtering based on both log scope and level. This has worked very well in practice while working on the self hosted compiler.
2021-10-24 13:13:06 +02:00
.info => "info",
.debug => "debug",
Expose mechanism to convert log level to text
2021-06-24 04:30:05 -06:00
};
}
Introduce std.log std.log provides 8 log levels and corresponding logging functions. It allows the user to override the logging "backend" by defining root.log and to override the default log level by defining root.log_level. Logging functions accept a scope parameter which allows the implementer of the logging "backend" to filter logging by library as well as level. Using the standardized syslog [1] log levels ensures that std.log will be flexible enough to work for as many use-cases as possible. If we were to stick with only 3/4 log levels, std.log would be insufficient for large and/or complex projects such as a kernel or display server. [1]: https://tools.ietf.org/html/rfc5424#section-6.2.1
2020-05-15 17:10:56 +02:00
};
fix another round of regressions in this branch * std.log: still print error messages in ReleaseSmall builds. - when start code gets an error code from main, it uses std.log.err to report the error. this resulted in a test failure because ReleaseSmall wasn't printing `error: TheErrorCode` when an error was returned from main. But that seems like it should keep working. So I changed the std.log defaults. I plan to follow this up with a proposal to change the names of and reduce the quantity of the log levels. * warning emitted when using -femit-h when using stage1 backend; fatal log message when using -femit-h with self-hosted backend (because the feature is not yet available) * fix double `test-cli` build steps in zig's build.zig * update docgen to use new CLI * translate-c uses `-x c` and generates a temporary basename with a `.h` extension. Otherwise clang reports an error. * --show-builtin implies -fno-emit-bin * restore the compile error for using an extern "c" function without putting -lc on the build line. we have to know about the libc dependency up front. * Fix ReleaseFast and ReleaseSmall getting swapped when passing the value to the stage1 backend. * correct the zig0 CLI usage text. * update test harness code to the new CLI.
2020-09-26 21:03:38 -07:00
/// The default log level is based on build mode.
Introduce std.log std.log provides 8 log levels and corresponding logging functions. It allows the user to override the logging "backend" by defining root.log and to override the default log level by defining root.log_level. Logging functions accept a scope parameter which allows the implementer of the logging "backend" to filter logging by library as well as level. Using the standardized syslog [1] log levels ensures that std.log will be flexible enough to work for as many use-cases as possible. If we were to stick with only 3/4 log levels, std.log would be insufficient for large and/or complex projects such as a kernel or display server. [1]: https://tools.ietf.org/html/rfc5424#section-6.2.1
2020-05-15 17:10:56 +02:00
pub const default_level: Level = switch (builtin.mode) {
.Debug => .debug,
std.log: adjust default level for ReleaseSmall to include info it was kind of wild to not do this before. sorry!
2025-07-09 23:03:35 -07:00
.ReleaseSafe, .ReleaseFast, .ReleaseSmall => .info,
Introduce std.log std.log provides 8 log levels and corresponding logging functions. It allows the user to override the logging "backend" by defining root.log and to override the default log level by defining root.log_level. Logging functions accept a scope parameter which allows the implementer of the logging "backend" to filter logging by library as well as level. Using the standardized syslog [1] log levels ensures that std.log will be flexible enough to work for as many use-cases as possible. If we were to stick with only 3/4 log levels, std.log would be insufficient for large and/or complex projects such as a kernel or display server. [1]: https://tools.ietf.org/html/rfc5424#section-6.2.1
2020-05-15 17:10:56 +02:00
};
std: collect all options under one namespace
2023-01-03 19:37:11 +02:00
const level = std.options.log_level;
Introduce std.log std.log provides 8 log levels and corresponding logging functions. It allows the user to override the logging "backend" by defining root.log and to override the default log level by defining root.log_level. Logging functions accept a scope parameter which allows the implementer of the logging "backend" to filter logging by library as well as level. Using the standardized syslog [1] log levels ensures that std.log will be flexible enough to work for as many use-cases as possible. If we were to stick with only 3/4 log levels, std.log would be insufficient for large and/or complex projects such as a kernel or display server. [1]: https://tools.ietf.org/html/rfc5424#section-6.2.1
2020-05-15 17:10:56 +02:00
Provide method to set logging level per scope (#8584)
2021-06-09 10:23:45 +01:00
pub const ScopeLevel = struct {
std: update `std.builtin.Type` fields to follow naming conventions The compiler actually doesn't need any functional changes for this: Sema does reification based on the tag indices of `std.builtin.Type` already! So, no zig1.wasm update is necessary. This change is necessary to disallow name clashes between fields and decls on a type, which is a prerequisite of #9938.
2024-08-28 02:35:53 +01:00
scope: @Type(.enum_literal),
Provide method to set logging level per scope (#8584)
2021-06-09 10:23:45 +01:00
level: Level,
};
std: collect all options under one namespace
2023-01-03 19:37:11 +02:00
const scope_levels = std.options.log_scope_levels;
Provide method to set logging level per scope (#8584)
2021-06-09 10:23:45 +01:00
Introduce std.log std.log provides 8 log levels and corresponding logging functions. It allows the user to override the logging "backend" by defining root.log and to override the default log level by defining root.log_level. Logging functions accept a scope parameter which allows the implementer of the logging "backend" to filter logging by library as well as level. Using the standardized syslog [1] log levels ensures that std.log will be flexible enough to work for as many use-cases as possible. If we were to stick with only 3/4 log levels, std.log would be insufficient for large and/or complex projects such as a kernel or display server. [1]: https://tools.ietf.org/html/rfc5424#section-6.2.1
2020-05-15 17:10:56 +02:00
fn log(
comptime message_level: Level,
std: update `std.builtin.Type` fields to follow naming conventions The compiler actually doesn't need any functional changes for this: Sema does reification based on the tag indices of `std.builtin.Type` already! So, no zig1.wasm update is necessary. This change is necessary to disallow name clashes between fields and decls on a type, which is a prerequisite of #9938.
2024-08-28 02:35:53 +01:00
comptime scope: @Type(.enum_literal),
Introduce std.log std.log provides 8 log levels and corresponding logging functions. It allows the user to override the logging "backend" by defining root.log and to override the default log level by defining root.log_level. Logging functions accept a scope parameter which allows the implementer of the logging "backend" to filter logging by library as well as level. Using the standardized syslog [1] log levels ensures that std.log will be flexible enough to work for as many use-cases as possible. If we were to stick with only 3/4 log levels, std.log would be insufficient for large and/or complex projects such as a kernel or display server. [1]: https://tools.ietf.org/html/rfc5424#section-6.2.1
2020-05-15 17:10:56 +02:00
comptime format: []const u8,
run zig fmt on std lib and self hosted
2020-07-11 14:09:04 +03:00
args: anytype,
Introduce std.log std.log provides 8 log levels and corresponding logging functions. It allows the user to override the logging "backend" by defining root.log and to override the default log level by defining root.log_level. Logging functions accept a scope parameter which allows the implementer of the logging "backend" to filter logging by library as well as level. Using the standardized syslog [1] log levels ensures that std.log will be flexible enough to work for as many use-cases as possible. If we were to stick with only 3/4 log levels, std.log would be insufficient for large and/or complex projects such as a kernel or display server. [1]: https://tools.ietf.org/html/rfc5424#section-6.2.1
2020-05-15 17:10:56 +02:00
) void {
std.log: add functionality to check if a specific log level and scope are enabled
2022-10-26 21:03:02 +01:00
if (comptime !logEnabled(message_level, scope)) return;
std: collect all options under one namespace
2023-01-03 19:37:11 +02:00
std.options.logFn(message_level, scope, format, args);
std.log: add functionality to check if a specific log level and scope are enabled
2022-10-26 21:03:02 +01:00
}
Provide method to set logging level per scope (#8584)
2021-06-09 10:23:45 +01:00
std.log: add functionality to check if a specific log level and scope are enabled
2022-10-26 21:03:02 +01:00
/// Determine if a specific log message level and scope combination are enabled for logging.
std: update `std.builtin.Type` fields to follow naming conventions The compiler actually doesn't need any functional changes for this: Sema does reification based on the tag indices of `std.builtin.Type` already! So, no zig1.wasm update is necessary. This change is necessary to disallow name clashes between fields and decls on a type, which is a prerequisite of #9938.
2024-08-28 02:35:53 +01:00
pub fn logEnabled(comptime message_level: Level, comptime scope: @Type(.enum_literal)) bool {
std.log: add functionality to check if a specific log level and scope are enabled
2022-10-26 21:03:02 +01:00
inline for (scope_levels) |scope_level| {
all: zig fmt and rename "@XToY" to "@YFromX" Signed-off-by: Eric Joldasov <bratishkaerik@getgoogleoff.me>
2023-06-15 13:14:16 +06:00
if (scope_level.scope == scope) return @intFromEnum(message_level) <= @intFromEnum(scope_level.level);
Introduce std.log std.log provides 8 log levels and corresponding logging functions. It allows the user to override the logging "backend" by defining root.log and to override the default log level by defining root.log_level. Logging functions accept a scope parameter which allows the implementer of the logging "backend" to filter logging by library as well as level. Using the standardized syslog [1] log levels ensures that std.log will be flexible enough to work for as many use-cases as possible. If we were to stick with only 3/4 log levels, std.log would be insufficient for large and/or complex projects such as a kernel or display server. [1]: https://tools.ietf.org/html/rfc5424#section-6.2.1
2020-05-15 17:10:56 +02:00
}
all: zig fmt and rename "@XToY" to "@YFromX" Signed-off-by: Eric Joldasov <bratishkaerik@getgoogleoff.me>
2023-06-15 13:14:16 +06:00
return @intFromEnum(message_level) <= @intFromEnum(level);
std.log: add functionality to check if a specific log level and scope are enabled
2022-10-26 21:03:02 +01:00
}
/// Determine if a specific log message level using the default log scope is enabled for logging.
pub fn defaultLogEnabled(comptime message_level: Level) bool {
return comptime logEnabled(message_level, default_log_scope);
Introduce std.log std.log provides 8 log levels and corresponding logging functions. It allows the user to override the logging "backend" by defining root.log and to override the default log level by defining root.log_level. Logging functions accept a scope parameter which allows the implementer of the logging "backend" to filter logging by library as well as level. Using the standardized syslog [1] log levels ensures that std.log will be flexible enough to work for as many use-cases as possible. If we were to stick with only 3/4 log levels, std.log would be insufficient for large and/or complex projects such as a kernel or display server. [1]: https://tools.ietf.org/html/rfc5424#section-6.2.1
2020-05-15 17:10:56 +02:00
}
std.log.defaultLog: provide a small buffer
2025-07-10 12:41:26 -07:00
/// The default implementation for the log function. Custom log functions may
std: collect all options under one namespace
2023-01-03 19:37:11 +02:00
/// forward log messages to this function.
std.log.defaultLog: provide a small buffer
2025-07-10 12:41:26 -07:00
///
/// Uses a 64-byte buffer for formatted printing which is flushed before this
/// function returns.
Expose default std.log implementation This allows root.log implementations to capture log messages, process them, and forward them to the default implementation if desired.
2021-06-24 04:11:28 -06:00
pub fn defaultLog(
comptime message_level: Level,
std: update `std.builtin.Type` fields to follow naming conventions The compiler actually doesn't need any functional changes for this: Sema does reification based on the tag indices of `std.builtin.Type` already! So, no zig1.wasm update is necessary. This change is necessary to disallow name clashes between fields and decls on a type, which is a prerequisite of #9938.
2024-08-28 02:35:53 +01:00
comptime scope: @Type(.enum_literal),
Expose default std.log implementation This allows root.log implementations to capture log messages, process them, and forward them to the default implementation if desired.
2021-06-24 04:11:28 -06:00
comptime format: []const u8,
args: anytype,
) void {
Expose mechanism to convert log level to text
2021-06-24 04:30:05 -06:00
const level_txt = comptime message_level.asText();
Expose default std.log implementation This allows root.log implementations to capture log messages, process them, and forward them to the default implementation if desired.
2021-06-24 04:11:28 -06:00
const prefix2 = if (scope == .default) ": " else "(" ++ @tagName(scope) ++ "): ";
std.log.defaultLog: provide a small buffer
2025-07-10 12:41:26 -07:00
var buffer: [64]u8 = undefined;
const stderr = std.debug.lockStderrWriter(&buffer);
defer std.debug.unlockStderrWriter();
nosuspend stderr.print(level_txt ++ prefix2 ++ format ++ "\n", args) catch return;
Expose default std.log implementation This allows root.log implementations to capture log messages, process them, and forward them to the default implementation if desired.
2021-06-24 04:11:28 -06:00
}
std.log: add documentation for scoped logging * Add short documentation to std.log.scoped and std.log.default * Update the module documentation and example to explain the difference between using explicit scopes, using a scoped logging namespace, and using the default namespace
2020-08-12 15:37:56 +02:00
/// Returns a scoped logging namespace that logs all messages using the scope
/// provided here.
std: update `std.builtin.Type` fields to follow naming conventions The compiler actually doesn't need any functional changes for this: Sema does reification based on the tag indices of `std.builtin.Type` already! So, no zig1.wasm update is necessary. This change is necessary to disallow name clashes between fields and decls on a type, which is a prerequisite of #9938.
2024-08-28 02:35:53 +01:00
pub fn scoped(comptime scope: @Type(.enum_literal)) type {
std.log: add scoped logging struct * Add a std.log.scoped function that returns a scoped logging struct * Add a std.log.default struct that logs using the .default scope Implementation of daurnimator's proposal: https://github.com/ziglang/zig/issues/5943#issuecomment-669043489 Note that I named the function "scoped" instead of "scope" so as not to clash with the scope parameter that is used everywhere; this seemed a better solution to me than renaming the scope parameter to "s" or "log_scope" or the like.
2020-08-12 14:03:02 +02:00
return struct {
std.log: simplify to 4 distinct log levels Over the last year of using std.log in practice, it has become clear to me that having the current 8 distinct log levels does more harm than good. It is too subjective which level a given message should have which makes filtering based on log level weaker as not all messages will have been assigned the log level one might expect. Instead, more granular filtering should be achieved by leveraging the logging scope feature. Filtering based on a combination of scope and log level should be sufficiently powerful for all use-cases. Note that the self hosted compiler has already limited itself to 4 distinct log levels for many months and implemented granular filtering based on both log scope and level. This has worked very well in practice while working on the self hosted compiler.
2021-10-24 13:13:06 +02:00
/// Log an error message. This log level is intended to be used
/// when something has gone wrong. This might be recoverable or might
/// be followed by the program exiting.
std.log: add scoped logging struct * Add a std.log.scoped function that returns a scoped logging struct * Add a std.log.default struct that logs using the .default scope Implementation of daurnimator's proposal: https://github.com/ziglang/zig/issues/5943#issuecomment-669043489 Note that I named the function "scoped" instead of "scope" so as not to clash with the scope parameter that is used everywhere; this seemed a better solution to me than renaming the scope parameter to "s" or "log_scope" or the like.
2020-08-12 14:03:02 +02:00
pub fn err(
comptime format: []const u8,
args: anytype,
) void {
compiler,lib,test,langref: migrate `@setCold` to `@branchHint`
2024-08-24 16:16:53 +01:00
@branchHint(.cold);
std.log: add scoped logging struct * Add a std.log.scoped function that returns a scoped logging struct * Add a std.log.default struct that logs using the .default scope Implementation of daurnimator's proposal: https://github.com/ziglang/zig/issues/5943#issuecomment-669043489 Note that I named the function "scoped" instead of "scope" so as not to clash with the scope parameter that is used everywhere; this seemed a better solution to me than renaming the scope parameter to "s" or "log_scope" or the like.
2020-08-12 14:03:02 +02:00
log(.err, scope, format, args);
}
std.log: don't state in docs that messages are logged to stderr Since the logger implementation can be overridden, the messages might not be logged to stderr at all.
2020-08-12 15:54:21 +02:00
/// Log a warning message. This log level is intended to be used if
std.log: add scoped logging struct * Add a std.log.scoped function that returns a scoped logging struct * Add a std.log.default struct that logs using the .default scope Implementation of daurnimator's proposal: https://github.com/ziglang/zig/issues/5943#issuecomment-669043489 Note that I named the function "scoped" instead of "scope" so as not to clash with the scope parameter that is used everywhere; this seemed a better solution to me than renaming the scope parameter to "s" or "log_scope" or the like.
2020-08-12 14:03:02 +02:00
/// it is uncertain whether something has gone wrong or not, but the
/// circumstances would be worth investigating.
pub fn warn(
comptime format: []const u8,
args: anytype,
) void {
log(.warn, scope, format, args);
}
std.log: don't state in docs that messages are logged to stderr Since the logger implementation can be overridden, the messages might not be logged to stderr at all.
2020-08-12 15:54:21 +02:00
/// Log an info message. This log level is intended to be used for
std.log: add scoped logging struct * Add a std.log.scoped function that returns a scoped logging struct * Add a std.log.default struct that logs using the .default scope Implementation of daurnimator's proposal: https://github.com/ziglang/zig/issues/5943#issuecomment-669043489 Note that I named the function "scoped" instead of "scope" so as not to clash with the scope parameter that is used everywhere; this seemed a better solution to me than renaming the scope parameter to "s" or "log_scope" or the like.
2020-08-12 14:03:02 +02:00
/// general messages about the state of the program.
pub fn info(
comptime format: []const u8,
args: anytype,
) void {
log(.info, scope, format, args);
}
std.log: don't state in docs that messages are logged to stderr Since the logger implementation can be overridden, the messages might not be logged to stderr at all.
2020-08-12 15:54:21 +02:00
/// Log a debug message. This log level is intended to be used for
std.log: add scoped logging struct * Add a std.log.scoped function that returns a scoped logging struct * Add a std.log.default struct that logs using the .default scope Implementation of daurnimator's proposal: https://github.com/ziglang/zig/issues/5943#issuecomment-669043489 Note that I named the function "scoped" instead of "scope" so as not to clash with the scope parameter that is used everywhere; this seemed a better solution to me than renaming the scope parameter to "s" or "log_scope" or the like.
2020-08-12 14:03:02 +02:00
/// messages which are only useful for debugging.
pub fn debug(
comptime format: []const u8,
args: anytype,
) void {
log(.debug, scope, format, args);
}
};
}
std.log: add functionality to check if a specific log level and scope are enabled
2022-10-26 21:03:02 +01:00
pub const default_log_scope = .default;
std.log: add documentation for scoped logging * Add short documentation to std.log.scoped and std.log.default * Update the module documentation and example to explain the difference between using explicit scopes, using a scoped logging namespace, and using the default namespace
2020-08-12 15:37:56 +02:00
/// The default scoped logging namespace.
std.log: add functionality to check if a specific log level and scope are enabled
2022-10-26 21:03:02 +01:00
pub const default = scoped(default_log_scope);
std.log: (breaking) remove scope parameter from logging functions The logging functions in std.log don't take a scope parameter anymore, but use the .default scope. To provide your own scope, use the logging functions in std.log.scoped(.some_other_scope). As per nmichaels' suggestion: https://github.com/ziglang/zig/pull/6039#issuecomment-673148971
2020-08-13 16:50:38 +02:00
/// Log an error message using the default scope. This log level is intended to
std.log: simplify to 4 distinct log levels Over the last year of using std.log in practice, it has become clear to me that having the current 8 distinct log levels does more harm than good. It is too subjective which level a given message should have which makes filtering based on log level weaker as not all messages will have been assigned the log level one might expect. Instead, more granular filtering should be achieved by leveraging the logging scope feature. Filtering based on a combination of scope and log level should be sufficiently powerful for all use-cases. Note that the self hosted compiler has already limited itself to 4 distinct log levels for many months and implemented granular filtering based on both log scope and level. This has worked very well in practice while working on the self hosted compiler.
2021-10-24 13:13:06 +02:00
/// be used when something has gone wrong. This might be recoverable or might
/// be followed by the program exiting.
std.log: (breaking) remove scope parameter from logging functions The logging functions in std.log don't take a scope parameter anymore, but use the .default scope. To provide your own scope, use the logging functions in std.log.scoped(.some_other_scope). As per nmichaels' suggestion: https://github.com/ziglang/zig/pull/6039#issuecomment-673148971
2020-08-13 16:50:38 +02:00
pub const err = default.err;
/// Log a warning message using the default scope. This log level is intended
/// to be used if it is uncertain whether something has gone wrong or not, but
/// the circumstances would be worth investigating.
pub const warn = default.warn;
/// Log an info message using the default scope. This log level is intended to
/// be used for general messages about the state of the program.
pub const info = default.info;
/// Log a debug message using the default scope. This log level is intended to
/// be used for messages which are only useful for debugging.
pub const debug = default.debug;
Reference in New Issue Copy Permalink