Proposal: Extend log crate with contextual, typed, and fatal-level logging

[Saumya-R]

Motivation: Automotive Use Case

1. Contextual / Hierarchical Logging

• Current target (module path) is too flat for complex automotive applications where multiple layers/modules may reuse common subsystems.
• Developers need to distinguish who logged what not only by module but also by parent/ancestor context.
• Add optional hierarchical context (e.g. ECU → Subsystem → Component).
• Such context could be attached automatically (per logger instance) and optionally extended by the user.
• Enables better traceability of log origins in safety-critical systems.

2. Type-Aware Logging

• Today everything is stringified, discarding type info needed by automotive backends (e.g. DLT expects type fidelity: numeric vs string vs struct).
• Proposal: allow passing typed values directly (info!(42), info!("user_id" = 43), info!(User { id: 7 })).
• Preserves fidelity for DLT and similar tools, enables filtering/sorting, while staying backward-compatible and simple for developers.

3. Fatal Log Level

• Current Error conflates recoverable and unrecoverable failures.
• Add a Fatal level for logging critical, fail-stop conditions.
• Essential for automotive where safety hazards must be identified and escalated distinctly.

Benefits

• Improves interoperability with standards (e.g. DLT, AUTOSAR logging).
• Strengthens suitability for safety-critical domains (ISO 26262 compliance).
• Still lightweight: could be added as opt-in features, maintaining compatibility.

[Thomasdezeeuw]

1. Contextual / Hierarchical Logging

Note that target != module path, though it's the default. You can set the target yourself: info!(target: "my target"). I've personally used this for access log set a specific target which can then be used for filtering later.

• Current target (module path) is too flat for complex automotive applications where multiple layers/modules may reuse common subsystems.
• Developers need to distinguish who logged what not only by module but also by parent/ancestor context.
• Add optional hierarchical context (e.g. ECU → Subsystem → Component).
• Such context could be attached automatically (per logger instance) and optionally extended by the user.
• Enables better traceability of log origins in safety-critical systems.

I think this will add quite a bit of overhead if this entire hierarchy needs to be kept in memory. What I do is add an id to each log so they can be grouped. My use case is handling requests so it's easy, an id per request, I don't know what an equivalent would be in automotive software though. Would something like this be possible for your use case?

2. Type-Aware Logging

Have you tried key-value logging: https://docs.rs/log/latest/log/kv/index.html, it's fully typed.

3. Fatal Log Level

Duplicate of #334, which discusses adding additional logging level.

[tisonkun]

Contextual / Hierarchical Logging

This seems to be an insatnce of Logforth's (thread-local) Diagnostic and needs not to be a feature in log.

[tisonkun]

Fatal Log Level

From your description, this can be resolved either:

1. Move recoverable errors to the WARN level.
2. Tag fatal logs with a "fatal" target and specially handling it in the log impl.