Skip to content

remove std.log usage from std.Build.Cache in favor of proper error reporting #14950

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
Tracked by #14647
andrewrk opened this issue Mar 16, 2023 · 1 comment
Open
Tracked by #14647
Labels
contributor friendly This issue is limited in scope and/or knowledge of Zig internals. standard library This issue involves writing Zig code for the standard library. zig build system std.Build, the build runner, `zig build` subcommand, package management
Milestone

Comments

@andrewrk
Copy link
Member

Extracted from #14647.

log.err("failed parsing {s}: {s}", .{ dep_file_basename, error_buf.items });

log.err("failed parsing {s}: {s}", .{ dep_file_basename, error_buf.items });

The cache system is used by the build runner during build graph execution which is multi-threaded. Errors should be properly collected into their designated places, rather than written globally to a log function. Likewise, the compiler code that uses the Cache wants to store compilation errors in the appropriate place rather than, again, being written globally to a log function.

@andrewrk andrewrk added contributor friendly This issue is limited in scope and/or knowledge of Zig internals. standard library This issue involves writing Zig code for the standard library. zig build system std.Build, the build runner, `zig build` subcommand, package management labels Mar 16, 2023
@andrewrk andrewrk added this to the 0.11.0 milestone Mar 16, 2023
@andrewrk andrewrk modified the milestones: 0.11.0, 0.12.0 Jul 20, 2023
@Arnau478
Copy link
Contributor

Should we keep the log.err() calls? So, log.err() and after that returning an actual error, or just an error? I see advantages from both sides. Logging has the advantage of formatting, so there can be more information, not just an error type. However, that could lead to duplicate errors, as both the caller and callee may report it.

@andrewrk andrewrk modified the milestones: 0.14.0, 0.15.0 Feb 9, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
contributor friendly This issue is limited in scope and/or knowledge of Zig internals. standard library This issue involves writing Zig code for the standard library. zig build system std.Build, the build runner, `zig build` subcommand, package management
Projects
None yet
Development

No branches or pull requests

2 participants