Allow partial support for bevy_log in no_std

[bushrat011899]

Objective

• Fixes Add no_std support to bevy_log #18781

Solution

• Moved LogPlugin into its own file gated behind a new tracing feature.
• Used log instead of tracing where possible.
• Exposed a new tracing feature in bevy which enables bevy_log/tracing.
• Gated LogPlugin from DefaultPlugins on tracing feature.

Testing

• CI

---

Migration Guide

• If you were previously using bevy_log with default features disabled, enable the new std and tracing features.
• If you were using bevy with the default features disabled, enable the new tracing feature.

Notes

Almost all of the diffs in this PR come from moving LogPlugin into its own file. This just makes the PR less noisy, since the alternative is excessive #[cfg(feature = "tracing")] directives all over the plugin.

[github-actions]

It looks like your PR is a breaking change, but you didn't provide a migration guide.

Please review the instructions for writing migration guides, then expand or revise the content in the migration guides directory to reflect your changes.

[Shatur]

Maybe depend on bevy_log for other internal Bevy crates? 🤔

[bushrat011899]

Maybe depend on bevy_log for other internal Bevy crates? 🤔

Definitely could do that, but I'd save that for a follow-up, this is already pretty lengthy for a last-minute RC update.

[hukasu]

i commented on the issue, but tracing seems to work on no_std, unless liballoc is a blocker
https://docs.rs/tracing/latest/tracing/#crate-feature-flags

Edit: liballoc seems to be just extern crate alloc; which is already use in many places

[bushrat011899]

i commented on the issue, but tracing seems to work on no_std, unless liballoc is a blocker https://docs.rs/tracing/latest/tracing/#crate-feature-flags

Edit: liballoc seems to be just extern crate alloc; which is already use in many places

The issue is actually to do with no_atomic rather than no_std, but right now Bevy considers them synonymous. Trying to consider them as separate features further fragments the codebase for little gain, since getting no_atomic support in a no_std context is comparatively trivial.

I already have no_atomic PRs for tracing opened which would close the gap and allow tracing on all platforms (e.g., thumbv6m-none-eabi), just waiting for further review before they're merged.

[cart]

Ok I think this is the move for now, given the current approach. I think the "virality" of both std and web is a maintenance liability and an "ecosystem UX" liability. Needing to know what dependencies are "std" or "web" is something we should avoid thrusting on users (and ourselves) whenever possible.

I've written out a potential path forward here: #18799

[cBournhonesque]

The move from log to tracing is a pretty big breaking change, right?
I was using

use bevy::prelude::*;
use tracing::*;

everywhere in my library for convenience, and now this causes conflicts because bevy's prelude switched from using tracing::debug! to log::debug!

Even if I enable the tracing feature, it only seems to add debug_span!, error_span!, etc. to the bevy prelude, not debug!, error! from tracing crate.

If tracing feature is enabled, should the bevy::log::debug! macro be using the macro from tracing instead of log?

Used log instead of tracing where possible.

That's a pretty change as the macros from tracing and log have different capabilities/syntax. I wouldn't expect a PR to enable no_std for bevy_log to have such a big side-effect