#bevy_cli

1 messages · Page 2 of 1

rare kite
#

IMO reflection is only really useful if everything has it, as if we had language-level support. Otherwise it's a crapshoot whether inspection tools will ever be fully useful.

#

I find myself not using them sometimes because I know how many gaps there are. Many of those cases are my fault, it's just hard to stay on top of when it is opt in.

rocky oxide
#

Yeah, I find it quite frustrating to constantly be playing whack-a-mole manually

#

Still not sure of the right solution, but at least the problem is clearly recorded

rare kite
#

Yeah. Not clear cut if it would be a good call, but I find myself leaning that way, especially because of all the other things reflection unlocks, especially when you don't need to worry if your deps have it set up.

#

e.g. serialization, validation, inspection, modding, networking, etc etc

rocky oxide
#

Yeah. I want to see how an on-by-default lint changes the story here first but if we need to push it harder we can :p

rare kite
#

forcing registration also gives us affordances for doing even more validation/registry type stuff at startup.

#

You can do a lot of cool stuff if you know that codepath exists for all ECS data

true pulsar
rare kite
#

@vagrant frigate has done some truly arcane stuff to work around this at work.

rocky oxide
rare kite
#

linkme, and cargo metadata in macros at compile time

rocky oxide
#

It's by the wayside right now but no linkme needed

rare kite
#

What path are you taking?

#

We just ditched linkme.

rocky oxide
rare kite
#

Looks like inventory, I seem to recall that had some issues, don't remember what

rocky oxide
pale viper
#

@lapis scroll I'm writing a lint that allows users to force all components, resources, and events to implement reflect. Should I search for Reflect implementations, or is there another trait that I should use instead?

#

(Like I'm noticing PartialReflect and FromReflect... are there cases where those are enough, and should not raise a warning?)

#

(Or maybe Reflectable?)

lapis scroll
#

Reflect should be enough

#

That’s what the derive contains and what manual implementors (if there are any) will most likely be using

pale viper
#

(Specifically for the case of components and resources?)

lapis scroll
#

The only time you’d only implement only PartialReflect is if you’re creating your own custom dynamic type

#

Which is generally unlikely

pale viper
#

Ah, and in that scenario I should just skip over that type

#

Thank you!

lapis scroll
#

Yep! No problem!

pale viper
#

When I finish the lint, would you be interested in testing it?

#

If there's anyone who can find bugs / pain points in the lint, it would be you

lapis scroll
#

Yeah definitely!

#

I can try to help review too if you need it

#

Another lint worth considering is trivial trait registrations like #[reflect(Serialize)] if the trait derives Serialize

#

Though you’d probably only be able to make that work for type data exported by bevy_reflect

#

Unless you have type/trait information available to your lint?

pale viper
pale viper
lapis scroll
#

By type checking, does that include access to what traits a type implements?

fierce orbit
#

This suggestion seems trivial but I don't see a 🎟️ for it ... Would it be possible for there to be a lint that tells people to do this:

-    commands
-        .spawn(Transform::from_matrix(VOXEL_FROM_WORLD))
-        .insert(IrradianceVolume {
-            voxels: assets.irradiance_volume.clone(),
-            intensity: IRRADIANCE_VOLUME_INTENSITY,
-        })
-        .insert(LightProbe);
+    commands.spawn((
+        Transform::from_matrix(VOXEL_FROM_WORLD),
+        IrradianceVolume {
+            voxels: assets.irradiance_volume.clone(),
+            intensity: IRRADIANCE_VOLUME_INTENSITY,
+        },
+        LightProbe,
+    ));
rocky oxide
fierce orbit
rocky oxide
pale viper
#

I'm giving a talk on how the linter works next Bevy Meetup, if you want to learn more :)

lapis scroll
#

Wow that’s awesome!

#

Sorta sounds like a fun project to work on….

pale viper
#

It gets a little crazy at times. I'm half convinced the Rust language designers introduced pattern matching specifically for compiler devs

royal void
#

Basically looking for #[macro_export] and making sure all paths are qualified with $crate

pale viper
#

Ah, wait, turns out its harder than expected

royal void
#

Thanks for finding that for me

trail shale
#

Sasha (the author) would probably be interested about this kind of use case

rocky oxide
pale viper
foggy basin
pale viper
pale viper
#

My goal is to publish 0.1.0 by November 1st, so we're on pace

#

At this point I want to ask: what are the pain points of using the linter and the CLI as a whole, and how can we polish it before release?

#

I'm planning on publishing the linter even if the CLI isn't ready, since it's technically a standalone project, but I still want to coordinate and make sure everyone's on the same page

#

If there's any other issue that someone wants to add to the 0.1.0 milestone, now's your chance to speak :)

rocky oxide
fierce orbit
#

The install instructions aren't just cargo install bevy_lint and then running bevy_lint in your repo? 👀

civic forge
#

Is bevy_lint meant to require the specific nightly version to run?

#

I installed it with the following in a docker file

RUN rustup toolchain install nightly-2024-08-21 --component rustc-dev --component llvm-tools-preview
RUN cargo +nightly-2024-08-21 install --git https://github.com/TheBevyFlock/bevy_cli bevy_lint

And then in a separate stage copied the built executable (without the nightly-2024-08-21 toolchain)

COPY --from=bevy_lint /root/.cargo/bin/bevy_lint /root/.cargo/bin
COPY --from=bevy_lint /root/.cargo/bin/bevy_lint_driver /root/.cargo/bin

RUN bevy_lint

But this failed because the nightly-2024-08-21 toolchain is not in that stage (latest stable/nightly is).

twilit kraken
twilit kraken
#

Nevermind, got it figured out

foggy basin
#

Unfortunately I am currently not able to dedicate as much time to open source as I want to, so I cannot say yet if it will be ready by November 1st

pale viper
#

There are no installation instructions, which is why it's still in the 0.1.0 milestone :)

pale viper
#

librustc_driver.so can be found at ~/.rustup/toolchains/nightly-2024-08-21-TRIPLE/lib/librustc_driver.so

#

You may need to copy over other files that librustc_driver.so depends on

foggy basin
#

I was wondering, clippy also works with stable rust, but they ought to use the same APIs right? how do they do it, special magic because they are a rustup component?

pale viper
pale viper
foggy basin
royal void
#

bevy_lint might imply that you can do workspace.lints.bevy. Is that true?

pale viper
#

Let me test it real quick :)

#

Ah, nevermind. It appears to be currently broken

pale viper
pale viper
#

@rocky oxide thanks for the reviews! I realize that you're super busy right now, so I appreciate you taking the time to look them over :)

rocky oxide
pale viper
#

Embedding clippy_utils as a module (bevy_lint::clippy_utils) is distasteful, as it requires having a lot more code in the repository than what we usually need

trail shale
pale viper
#

Not publishing to crates.io means that users can't easily do cargo install bevy_lint, which I'd like to avoid

pale viper
#

I could look into it again, if that's the only good option, but it still wouldn't let us publish lints to crates.io

trail shale
#

yup, but it has a nice syntax to add your linter from git in the cargo.toml file

rocky oxide
#

Could we publish a fork of clippy_utils on our own?

trail shale
#

if there are issues in dylint, it would probably be nicer for the ecosystem to improve it rather than recode from scratch

rocky oxide
rocky oxide
trail shale
#

yes?

#

not sure I understand what you mean

rocky oxide
#

Like, I don't think that relying on Clippy's infrastructure is any worse than relying on dylint 🙂

#

And if we can prompt them to make it more reusable that would be great

trail shale
#

dylint is an helper on top of clippy

rocky oxide
#

Oh I see 🤔

pale viper
#

Standard linters like Clippy and bevy_lint fall into one category, while Dylint falls into another

pale viper
# pale viper
poll_question_text

How to address clippy_utils?

victor_answer_votes

1

total_votes

2

rocky oxide
#

Clippy team seems interested in doing this for us 😄

foggy basin
#

@pale viper I'm now getting hundreds of errors when trying to cargo check main, this didn't happen before.
Did anything with the setup change? Was bevy_lint optional before and required now?

image.png
#

Nevermind, rustup update && cargo clean && cargo check fixed it :)

pale viper
pale viper
lapis scroll
rocky oxide
rocky oxide
lapis scroll
#

Hm, I'm trying to get started in Rust Rover, but it seems like none of the types are being resolved correctly. Getting things like Unresolved import: `rustc_lint`

#

Any idea what set up steps I might need to take?

#

Looks like things work correctly with VSCode + RA

lapis scroll
#

Maybe it'll work in Fleet?

#

(or I could stop being a baby and use something other than IntelliJ)

pale viper
lapis scroll
#

It looks like it uses RA

#

But even that isn’t working haha

pale viper
#

Yup, then it should work as expected

#

Oh no!

#

What error are you getting?

lapis scroll
#

Yeah it’s weird. Gimme a sec I’ll pull up the error just in case there is something that we can do here

pale viper
lapis scroll
# pale viper What error are you getting?

This might not be specific to bevy_cli idk:

Failed to spawn one or more proc-macro servers.

- Failed to run proc-macro server from path ~/.rustup/toolchains/stable-aarch64-apple-darwin/libexec/rust-analyzer-proc-macro-srv, error: Custom { kind: Other, error: "proc-macro server's api version (5) is newer than rust-analyzer's (4)" }
pale viper
#

Ooooh that's a new one!

#

Looks like RA has an outdated language server protocol?

lapis scroll
lapis scroll
#

And it's fine if we can't get it working. I'm just very used to JetBrains products so it would have been great to be able to work on it in one of those IDEs

pale viper
#

Strange indeed. I'd try looking through Fleet's settings and bug tracker, but don't know after that

lapis scroll
#

Yeah it's probably just Fleet honestly

pale viper
#

I've been trying to switch to a modal editor like Helix, since it helps when jumping between symbols in code

lapis scroll
#

Yeah VSCode works fine, and is probably what I'll have to use if I can't find a solution

lapis scroll
#

Using this hack, I can almost get RustRover working. Now I'm just getting hit with:

error: failed to run custom build command for `rustc_macros v0.0.0 (~/.rustup/toolchains/nightly-2024-10-03-aarch64-apple-darwin/lib/rustlib/rustc-src/rust/compiler/rustc_macros)`

Caused by:
  process didn't exit successfully: `~/Projects/bevy_cli/target/debug/build/rustc_macros-9fcfb1b8cfc8bac6/build-script-build` (exit status: 101)
  --- stdout
  cargo:rerun-if-changed=build.rs
  cargo:rerun-if-env-changed=RUSTC_BOOTSTRAP

  --- stderr
  error: you are attempting to build the compiler without going through bootstrap
  help: see https://rustc-dev-guide.rust-lang.org/building/how-to-build-and-run.html for how to build the compiler
  help: if you know what you're doing, set the RUSTC_BOOTSTRAP environment variable to any value
Working with rustc - The Kani Rust Verifier

Documentation for the Kani Rust Verifier

#

Wait. I think I got it working

#

Okay so the trick is to not rely on RustRover's automatic Cargo.toml syncing

#

Instead, you have to first call cargo clean then build with cargo build or cargo check

#

(along with having added in the hack to your Cargo.toml)

#

Then autocomplete and stuff should work

#

Just don't click Load Cargo Changes lol

pale viper
#

Huh, that's really weird

#

Glad you got it figured out though!

toxic quartz
#

Anyone looked at updating bevy_new_2d for 0.15 yet? If not, I might do it as an exercise

pale viper
pale viper
#

@analog fern could you add me as an owner of bevy_lint on crates.io in preparation for its upcoming release?

#

My username is "BD103" :)

toxic quartz
lethal snow
lapis scroll
#

Yeah but I don’t think Fleet gives you control over what version it’s using :/

royal void
#

Switch off of Fleet I guess :p

analog fern
analog fern
rocky oxide
#

I would like to start getting user feedback and testing though, so it's worth discussing the best way to meet that need

#

There's only a few lints so far, and setup is a bit jank

#

But overall this seems very useful even now

lapis scroll
#

Yeah it sounds like it would be worth getting this into user’s hands early

#

Though I suppose it could probably still happen through git preleases?

#

Or maybe alpha releases on crates.io if we want to save the “official” release for a more polished state

rocky oxide
#

I'd also be really keen on a nice github actions for this, and testing that out on various ecosystem crates

trail shale
#

cargo install --git https://github.com/TheBevyFlock/bevy_cli.git bevy_lint seems a good way to have it used without any release

pale viper
#

I'll try my best to answer, though. My plan was to release 0.1.0 early so that users could begin testing out bevy_lint, even if it lacked a complete set of features and had a few rough edges

#

As Alice alluded to, there are a few lints that can already be useful to others, namely missing_reflect and panicking_methods. I'd like to get these setup in Bevy's CI and a few other popular 3rd party crates so I can get some actual feedback on them

#

I originally planned on releasing 0.1.0 November 1st on crates.io, then making small releases from there. Before now I hadn't really considered that you may want more thorough review of the crate for each release

#

In my mind bevy_lint has always been "unofficial and unstable", so I didn't think it needed that level of (for lack of a better word) bureaucracy

#

I imagined (and hoped!) that it would one day become officially adopted, but thought there would be a few releases before then

#

I hope that somewhat answers your question! If you have any concerns, additional questions, or ideas, please let me know! I'd be happy with a lot of solutions, I just want my work to become actually useful to others 😅

analog fern
# pale viper Could you go into a bit more detail on what you mean by "management / governance...

Could you go into a bit more detail on what you mean by "management / governance"?

In my mind, the publishing of a bevy_lint crate under that name would be a signal to people that this is an official Bevy project, whose defaults and implementation have gone through the "normal" process (controversial changes reviewed by SMEs and maintainers). This is especially important for lints because they have significant effects for Bevy developers. Lints are defining what "correct" Bevy code looks like, so pretty much every lint change is "controversial".

In my mind bevy_lint has always been "unofficial and unstable", so I didn't think it needed that level of (for lack of a better word) bureaucracy

I think this is a great way to do it. My only qualm is doing it under the umbrella of the name we intend to use upstream. I think that blurs the lines too much.

There are a few lints that can already be useful to others, namely missing_reflect and panicking_methods. I'd like to get these setup in Bevy's CI and a few other popular 3rd party crates so I can get some actual feedback on them

I'm on board for this. Provided the relevant people review the lints being adopted and we scope the CI to those lints specifically. You choosing to merge a new lint shouldn't arbitrarily result in Bevy adopting it. And any changes to existing lints would need to be discussed and approved ahead of time with leadership.

I imagined (and hoped!) that it would one day become officially adopted, but thought there would be a few releases before then

I'd also love for this to be how this plays out! My preference is that you do this under a different name, and then we use bevy_lint for whatever we end up upstreaming.

pale viper
#

(sorry I hit send too early, give me a second)

pale viper
# analog fern > Could you go into a bit more detail on what you mean by "management / governan...

In my mind, the publishing of a bevy_lint crate under that name would be a signal to people that this is an official Bevy project, whose defaults and implementation have gone through the "normal" process

That makes a lot more sense, thanks for the explanation!

You choosing to merge a new lint shouldn't arbitrarily result in Bevy adopting it.

My preference is that you do this under a different name, and then we use bevy_lint for whatever we end up upstreaming.

I understand your concern there. Here's my proposed solution:

What if bevy_lint releases "alpha" versions, just Git tags for version 0.0.1, 0.0.2, etc. When you run cargo install, you specify --tag v0.0.1 to install a specific version. (We can then add crates.io later, if / when it becomes official.)

Having a version system means that maintainers can look over the changelog of stabilized and enabled-by-default lints in bulk. It also means that CI is far less likely to break, since it won't be targeting main.

#

It's a bit difficult to disable lints as of right now, since the [lints.bevy] and [workspace.lints.bevy] tables don't work, you have to add #![allow(bevy::...)] to each crate root. I'm planning on adding support for loading a bevy.toml file with linter-specific configuration to amend this, but that's a later thing

pale viper
analog fern
trail shale
pale viper
analog fern
#

I think it would be good to prioritize linter config if the goal is to get projects like Bevy and popular plugins to adopt it

lapis scroll
#

How do I convert a rustc_hir::hir::Ty to a rustc_middle::ty::Ty?

#

Trying to copy this from another lint ICEs:

let ty = cx.typeck_results().node_type(ty.hir_id);
#

(context: I'm using LateLintPass::check_fn to get the function's inputs which is a rustc_hir::hir::Ty list)

lapis scroll
#

Okay I think this works (it's not blowing up at least haha):

let ty = cx.tcx.type_of(ty.hir_id.owner).instantiate_identity();
#

Not really sure how EarlyBinder and stuff works haha but I'm sure if I'm using it wrong, it'll come up in review (or here)

lapis scroll
#

Nvm that seems to return the type of the parent 🙃

pale viper
pale viper
#

EarlyBinder is for<'a>, it's used to "define" new lifetimes and generic types. I would experiment calling it on different generic expressions, and see the results

#

(Take a look at no_bound_vars(), skip_binder(), and plain instantiate())

#

Most of my existing knowledge is from those resources, asking on Rust Zulip occasionally, and calling dbg!() everything in lints

finite crag
#

Is a feature that diagnoses system errors planned?

#

something like:

#

Please explain to me why this fn does not implement IntoSystem.

#

I just spent a solid 15 minutes debugging some obscure function signature just to figure out I forgot to wrap a Resource type inside a Res<>

pale viper
#

Lints run after type checking, meaning the type needs to be valid for us to even inspect it

#

So while it is planned, it needs further investigation and might not be finished for a while

#

Sorry!

dusky onyx
rocky oxide
lapis scroll
# pale viper Could you send the error message? That should work, since you're within a body

Yeah I thought so too (once I learned that a Body includes the function arguments, assuming that's what it's referring to).

Not sure if you want the whole ICE, but here's the initial message:

error: internal compiler error: compiler/rustc_middle/src/ty/typeck_results.rs:334:13: node_type: no type for node HirId(DefId(0:10 ~ spoofed_name[9be2]::{impl#0}::build).11) (type `self`)
lapis scroll
lapis scroll
pale viper
lapis scroll
#

I want the type of the argument in the function signature. If it's a Commands, I want to see if we're taking a reference to it (i.e. &mut Commands). If so, we want the lint to suggest replacing it with an owned Commands and have callers simply reborrow

pale viper
#

The inputs are HIR Ty, but you should be able to lower them with cx.tcx

#

Wait, but that would be node_type(), huh…

#

Oh wait! @lapis scroll you need to skip &self arguments, that’s the issue

lapis scroll
#

Wait even if there's no receiver, it still contains a self?

#

Hm, it seems like it only contains a single type? This is the one I'm getting:

📎 message.txt
lapis scroll
pale viper
lapis scroll
#

Haven't made a branch yet since I'm still trying to get this part to give me the type haha, but i'll put one together

lapis scroll
#

Also let me know if there's a better way to debug. I've just been emitting lints and running the tests haha

pale viper
pale viper
#

It's a bit cursed, but it works 🤷‍♂️

pale viper
#

@lapis scroll so I managed to fix the initial error by skipping self types, since those are special-cased by the compiler and don't have an associated rustc_middle::ty::Ty

if let TyKind::Path(QPath::Resolved(_, Path { res: Res::SelfTyAlias { .. }, .. })) = ty.peel_refs().kind {
  continue;
}
#

But then I ran into a few other ICEs as well, so I just replaced node_type() with node_type_opt():

let Some(ty) = cx.typeck_results().node_type_opt(ty.hir_id) else {
  continue;
};
#

In the above code, if the type cannot be resolved, it simply exits and moves on to the next function argument

#

This is the patch file for my changes. You should be able to call git apply fix.patch (great name, I know) to apply them locally

📎 fix.patch
#

You shouldn't need to use TyCtxt::type_of() anymore, which is good since it doesn't work on expressions anyways. Let me know if you need anything else!

lapis scroll
#

Oh awesome, thanks for the help! I’ll try the patch out tomorrow

pale viper
#

If anyone has time for review, I have 5 PRs open that could use a set of eyes :)

lapis scroll
#

Or at least, it's not emitting anything for me

pale viper
#

Looks like they suggest tcx.fn_sig() to find the rustc_middle::ty::Ty of the inputs

#

I started fiddling around with this, though it requires binders:

fn check_fn(
    &mut self,
    cx: &LateContext<'tcx>,
    kind: FnKind<'tcx>,
    _: &'tcx FnDecl<'tcx>,
    _: &'tcx Body<'tcx>,
    _: Span,
    def_id: LocalDefId,
) {
    if let FnKind::ItemFn(ident, _, _) | FnKind::Method(ident, _) = kind {
        dbg!(ident);

        let fn_sig = cx.tcx.fn_sig(def_id).instantiate_identity();

        let inputs = fn_sig.inputs();
    }
}
#

Not sure how to move on from here, though. Maybe open a thread in the Clippy channel on the Rust Zulip?

lapis scroll
#

I’ll look into it

#

Sorry for not giving it my full debugging attention haha it’s been pretty busy

pale viper
#

No worries lol

#

As you’ve probably learned, compilers are hard

lapis scroll
#

Before I take it out of draft, I'm curious if we should add support for the other re-borrowable types (e.g. Mut, EntityMut, FilteredResourcesMut, etc.)

#

Or I guess we could also punt that decision off into a followup PR

pale viper
#

Yay! super_bevy I’m a bit busy right now, but I’ll take a look by Thursday :)

lapis scroll
#

No rush. I barely have time to work on things these days anyways 🥲

snow linden
#

so remind me, what is this group for again?

rocky oxide
snow linden
pale viper
#

:D

lapis scroll
snow linden
#

help me understand, this is on a different repo owned by a different org

#

whats the goal here?

rocky oxide
lapis scroll
#

Lol it was merged just as I was finishing my review with suggestions 😭

rocky oxide
#

Sorry though 😅

lapis scroll
#

Haha not your fault, I'm really slow with finishing reviews

#

I'll make an issue!

rocky oxide
#

And we want to make sure that any on-by-default lints have sign off from Bevy leadership

#

Since they can seriously degrade the developer experience and promote weird patterns if we get them wrong

lapis scroll
pale viper
# snow linden whats the goal here?

To add on to what @rocky oxide said, TheBevyFlock is an organization owned by @trail shale that we throw prototype and unofficial projects on

#

bevy_new_2d is there, and so is flag-frenzy and bevy-bencher

#

The eventual goal with these projects are to flesh them out enough to see whether they could become official projects

#

While there's a good chance that bevy_lint will be upstreamed before bevy_cli (and the linter is designed with this in mind), they were started together

#

Let me know if you have any further questions! :)

foggy basin
#

I reached another milestone to get the Web UX on par with the Native UX. You can now just do bevy run --example breakout web and it works without further configuration!
Code still needs to be cleaned (and probably split) up, but the functionality is implemented.

image.png
snow linden
#

at one point someone talked about auto-patching of repos

#

like, having the ci autogenerate cargo overrides for all the bevy crates

#

is that implemented?

foggy basin
lapis scroll
#

@pale viper would you happen to have any insight here ?

Zulip
#

I just want a span for the given middle::Ty 😭

#

I might just have to do my parsing via manually matching hir::TyKind if it's not possible

pale viper
lapis scroll
#

Darn

pale viper
#

There can be multiple hir::Ty for a single type String, but there will only ever be one middle::Ty for String

lapis scroll
#

Yeah I wasn’t sure if there was a way to track the specific hir type

#

But it’s fine it shouldn’t be too hard to rewrite to use hir

pale viper
#

It may be possible to find a list of all hir::Ty in a crate for a specific middle::Ty, but that sounds expensive

#

Speaking of which, this reminds me to review your PR. I'll be sure to do so by the end of today :)

lapis scroll
#

Oh right haha. Again no rush lol

lapis scroll
pale viper
lapis scroll
#

Not sure. I could try to see if there is. My current method is also a bit hacky:

/// Returns the [`GenericArg`] at the given index.
fn generic_at<'tcx>(ty: Ty<'tcx>, index: usize) -> Option<GenericArg<'tcx>> {
    let mut walker = ty.walk().skip(index + 1);
    let arg = walker.next()?;
    Some(arg)
}

/// Returns the list of types inside a tuple type.
///
/// If the type is not a tuple, returns a list containing the type itself.
fn detuple<'tcx>(ty: Ty<'tcx>) -> Vec<Ty<'tcx>> {
    if let TyKind::Tuple(items) = ty.peel_refs().kind() {
        items.to_vec()
    } else {
        vec![ty]
    }
}
#

I also considered making the check_ty operate on the generic type itself, then check for Query in the parent, but I think I ran into an issue there as well (iirc the parent ended up being the function rather than the Query)

#

But if that could work, then getting the span is trivial

#

Oh but then I'd still need to check if the type is in the QueryData position

#

Nvm then haha

#

Yeah matching the hir sounds like the simplest approach

#

I think I saw another lint in the repo do a similar thing to extract the span

pale viper
#

GenericArg::Ty has an hir::Ty, which can give you the span you're looking for

lapis scroll
# lapis scroll I think I saw another lint in the repo do a similar thing to extract the span

Yeah looks like insert_event_resource does this:

// This is some crazy pattern matching. Let me walk you through it:
let event_span = match events_hir_ty.kind {
    // There are multiple kinds of HIR types, but we're looking for a path to a type
    // definition. This path is likely `Events`, and contains the generic argument that we're
    // searching for.
    rustc_hir::TyKind::Path(QPath::Resolved(
        _,
        &Path {
            // There can be multiple segments in a path, such as if it were
            // `bevy::prelude::Events`, but in this case we just care about the last: `Events`.
            segments:
                &[.., PathSegment {
                    // Find the arguments to `Events<T>`, extracting `T`.
                    args:
                        Some(&GenericArgs {
                            args: &[GenericArg::Type(ty)],
                            ..
                        }),
                    ..
                }],
            ..
        },
    )) => {
        // We now have the HIR type `T` for `Events<T>`, let's return its span.
        ty.span
    }
    // Something in the above pattern matching went wrong, likely due to an edge case. For
    // this, we set the applicability to `HasPlaceholders` and return the default snippet.
    _ => {
        if let Applicability::MachineApplicable = applicability {
            *applicability = Applicability::HasPlaceholders;
        }

        return DEFAULT;
    }
};
lapis scroll
pale viper
lapis scroll
#

Oh gotcha

#

That's not annoying lol

pale viper
#

I've never quite figured out how to differentiate between the two variants in code, since their imports would conflict

lapis scroll
#

How would I get GenericArg?

#

The search results for return position don't seem to be very useful

#

Ah looks like I can maybe get it from the hir::Node?

pale viper
lapis scroll
#

Oh I see

#

Okay I'll try to work on this some more and come back with any followup questions 😅

pale viper
#

Yup! It's quite literally drilling through the type system

pale viper
lapis scroll
lapis scroll
#

Are there any objections to moving some of the helper functions in this PR to a dedicated hir_parse_utils module or something?

#

I think I want to use them again for another lint (assuming there aren't any issues with them lol)

royal void
#

I don't like utils modules, but I admit it can be useful if you don't want a separate crate.

lapis scroll
#

Yeah I know there's a similar sentiment among others (I personally don't mind a utils module, especially if properly scoped or given well-named sub-modules)

#

What if we called the module hir_parse?

lapis scroll
rocky oxide
lapis scroll
#

I can start with that and we can iterate as necessary

lapis scroll
#

Essentially moving the runtime conflicting access check to compile time (via a lint)

pale viper
pale viper
lapis scroll
lapis scroll
#

Can we turn off the This workflow requires approval from a maintainer. for CI?

#

I just pushed changes that should fix my CI errors, but I can't see if they truly worked until the workflow is manually approved 😅

#

(it was a simple fix so I'm pretty sure it did, but I mean more for the future)

pale viper
lapis scroll
#

Oh I had no idea that was even an option. Neat!

worn jetty
#

Hey, do you people think it would sense to integrate a bevy-specific documentation generating process (basically rustdoc + extensions) for things like this #documentation-dev message into the CLI?

foggy basin
#

The reworked binary detection is ready for review: https://github.com/TheBevyFlock/bevy_cli/pull/169
It's a big PR, but hard to entangle unfortunately.
But with it, we can now run every bevy example in the browser without additional configuration!

foggy basin
worn jetty
# foggy basin What would be the steps needed to implement something like this?
  1. Run the parser, which creates mermaid files
  2. Run mermaid to create SVGs
  3. Include SVGs into doc comments

The last step is currently still manual, but it's wip. There were also ideas in documentation dev to automatically generate the docs with the process macro. So maybe it isn't needed after all.

Nevertheless I think it's a cool idea for a project as complex as bevy to automatically enrich the docs by things we can parse as an extra step before or after rustdoc

foggy basin
rocky oxide
#

They're very receptive!

pale viper
#

Question: should the first release of bevy_lint support Bevy 0.14 or 0.15?

rocky oxide
pale viper
#

We don't currently have the technology to support both, so we have to choose. Going for 0.14 will allow for quick adoption, but may hold back the ecosystem when 0.15 is released. Supporting 0.15 hurts people using prior versions who cannot update quickly

rocky oxide
pale viper
pale viper
#

We can always backport to support older versions, as well, for the epic people at Foresight and such

rocky oxide
#

locale = bevy_0.14

pale viper
#

@rocky oxide and @twilit dew you may be interested, but no stress :)

rocky oxide
#

Otherwise we end up having to write our own "map this special string to this other string based on a global config value" layer

#

Which isn't that complex, but the problem domain really feels like it has the same shape

#

Mostly a matter of pulling in the dependency or not IMO

#

(in theory we could localize help / error strings too, on the basis of language)

rocky oxide
foggy basin
#

Did match allow ranges with anything implementing partial order? if yes, I would suggest to match on a semver object of the bevy version.
That would be simple to implement and only uses dependencies we already have

pale viper
#

Looks like you can't use range patterns on non-literals

# 
match two {
    PartialNum(0)..PartialNum(3) => println!("Yes!"),
    _ => println!("Oh no!"),
}
#

^ results in compiler error

#

I do like the idea of using the semver crate! I was originally just going to have an enum with variants for major Bevy versions, but semver allows for a lot more control

#

(Especially since changes that aren't breaking for users could be breaking for us)

quaint cipher
# pale viper Looks like you can't use range patterns on non-literals

This nerdsniped me; more precisely you can't use range patterns on anything that isn't a char or a primitive number. You can use it with constants of those types as well as literals, but nothing else. There is also a nightly feature for inline const expressions in patterns, which lets you modify the code snippet to const { PartialNum(0) }..const { PartialNum(3) } and avoid the syntax error, but that still throws the same type error you get from using named consts.

pale viper
quaint cipher
#

There's been some discussion of it that I found, but most pattern matching things use the marker trait StructuralPartialEq to ensure that the runtime and compile time behaviour agree when matching on constants; this trait can only be added by deriving PartialEq rather than manually implementing it. The decision a few years ago seems to have been that an equivalent would be needed for StructuralPartialOrd to ensure it is well behaved, but that it would end up being needing a bunch of attributes to control the derived PartialOrd for it to actually be useful in cases where a custom implementation is needed.

foggy basin
#

I guess a primitive if else also works although its not as pretty :D

pale viper
#

<@&1064695155975803020> I believe bevy_lint is ready to kick off the release of v0.1.0! Please take this time to review its current features and documentation, then leave your review at https://github.com/TheBevyFlock/bevy_cli/pull/172. If you have any questions or issues that you want to bring up, please do not hesitate to ping me in this channel or on the PR. Thank you!

lapis scroll
#

I also think I fixed the problem with closures, but uncovered another issue in the process (made a ticket already)

lapis scroll
royal void
#

@lapis scroll what is 'tcx?

#

Is that supposed to be context?

#

ctx?

lapis scroll
#

I think it’s short for “type context”

#

Seems to be a convention from what I can tell

#

Which is also why I use cx instead of ctx. Just seems to be what’s used

#

(even though I typically prefer the latter haha)

toxic quartz
#

huh, TIL

pale viper
#

It’s similar to 'static in that way. It was introduced because most data is stored in long-lived memory arenas

#

Whenever a lint accesses the HIR, AST, or an evaluated type, it always works on references instead of owned data because of this fact

pale viper
#

Thank you all so much for your help along the way, I truly appreciate it 💙

rocky oxide
pale viper
rocky oxide
#

(in seperate PRs)

pale viper
#

It probably won't be useful in CI until v0.2.0, where I plan on adding support for configuring lints for an entire workspace

rocky oxide
pale viper
#

Of the existing lints, I think missing_reflect and panicking_methods would be the most useful, but also the most annoying to fix due to how many cases there may be :)

rocky oxide
rocky oxide
#

Slowly enabling it will be good

molten merlin
pale viper
toxic quartz
pale viper
royal void
#

The ) is messing up the link for me lol

limber wedge
#

Hey there im looking for a relative easy first issue to contribute to the linter. I found this https://github.com/TheBevyFlock/bevy_cli/issues/15 is this something that i can try to implement or should we wait to see if this will no longer be required after the addition from @ekuber as mentioned: https://github.com/TheBevyFlock/bevy_cli/issues/15#issuecomment-2336835073

GitHub
Detect duplicate bevy dependencies · Issue #15 · TheBevyFlock/bevy_...

An issue that many beginners have when using Bevy is having duplicates of it within the dependencies. This usually happens when a user adds 3rd party crates that don't support the same major ve...

rocky oxide
pale viper
#

All lints are inside of the lints module. Check out mod.rs for registering your lint and missing_reflect.rs for a good example

#

You may even be able to create an EarlyLintPass, but I wouldn't worry about doing that right now

limber wedge
#

thanks for all the helpful links!

pale viper
#

The most relevant crates to you are going to be clippy_utils, rustc_hir, rustc_middle, and rustc_lint. You may also want to familiarize yourself with the TyCtxt type, which lets you query information from the compiler

TyCtxt in rustc_middle::ty - Rust

The central data structure of the compiler. It stores references to the various arenas and also houses the results of the various compiler queries that have been performed. See the rustc dev guide for more details.

pale viper
# limber wedge thanks for all the helpful links!

Of course! If you run into trouble, please don't be afraid to reach out to me in this channel or privately. If I'm not around, you can also ask @lapis scroll questions, since he's also written a few lints :)

limber wedge
limber wedge
#

do you know how i can get the version of a crate? @pale viper

impl<'tcx> LateLintPass<'tcx> for DuplicatBevyDependencies {
    fn check_crate(&mut self, cx: &LateContext<'tcx>) {
        let bevy_crates = find_crates(cx.tcx,Symbol::intern("bevy"));

        for bevy_crate in bevy_crates {
            if let Res::Def(_, def_id) = bevy_crate {
              // what now? 
            }
        }
    }
}```
royal void
pale viper
#

For your case, I would just check if bevy_crates.len() > 1. Open a PR with that as a minimum viable lint, then we can work on better diagnostics :)

#

My thoughts are to fingerprint versions of Bevy's crates by checking if certain properties exist (such as structures that are added in newer versions, or removed in older ones), but I don't know how well that would work

#

You could also run cargo metadata to get a list of crates in the workspace, and check that for duplicates instead of going through rustc's lint process

royal void
#

Can the lint execute cargo tree?

#

When len > 1

Or the diagnostic can suggest it

limber wedge
limber wedge
rocky oxide
pale viper
rocky oxide
limber wedge
pale viper
#

Ok, PR is open for review! :)

tawny eagle
#

If you're looking for early adopters of bevy_lint, I'd be open to trying it on my project.

pale viper
tawny eagle
#

I have 62k lines of bevy rust code in the game so far.

What am I looking for? Avoiding any common mistakes, writing mostly to best practices, being able to incorporate this into CI so I don't have to think about it. (I enforce clippy and fmt on my CI.) And helping to establish and clarify those best practices for the community.

#

I'm able to track main. I tracked main for 0.15 and it worked out well for me, by spreading a painful migration over time instead of hitting me all at once.

pale viper
#

bevy_lint as a whole does three things: catch common mistakes, enforce a common style, and enable restricting your code. Common mistakes are things like calling init_resource::<Events<T>>() instead of add_event(), style are things like requiring all plugin names to end in "Plugin", and restrictions are lints that, for instance, let you force all components within a module to derive Reflect

tawny eagle
#

In my case, I mostly use fn plugins, as I find them more concise. I only use struct Plugins when I need to finalize (for renderer plugins, mostly). But yeah, at least I could offer some actual on the ground testing.

pale viper
#

If you want a quick plug-and-play experience, you'll get common mistakes and style enforcement out of the box. Restrictions require a bit more thinking, and depend a lot on how you structure your code

tawny eagle
#

Common mistakes and style enforcement is a good place to start. Restrictions are probably valuable to me (maybe around things like "how to extend commands") but yeah, I'm willing to put in thought.

pale viper
tawny eagle
#

Okay, I'll do that.

pale viper
#

I can help you setup CI, since the installation is a bit strange :)

#

Let me know if you run into any road bumps! There's an issue tracker here if anything is annoying or bugged

tawny eagle
#

Ok, I probably won't have time to fully tackle it until Monday.

pale viper
#

Do note that bevy_lint only has official support of 0.14. 0.15 will work in most cases, though I know for a fact bevy::insert_event_resource is broken

toxic quartz
#

Hm. This block is in bevy_new_2d, but it doesn't quite make sense to me 🤔 since there's nothing specifically platform-targeting here. Would a better description be, "Set max static log levels to debug by default, and warn for release builds"?

# Compile low-severity logs out of native builds for performance.
log = { version = "0.4", features = [
    "max_level_debug",
    "release_max_level_warn",
] }
# Compile low-severity logs out of web builds for performance.
tracing = { version = "0.1", features = [
    "max_level_debug",
    "release_max_level_warn",
] }
#

was gonna chuck it in minimal

near mist
#

the platform-targetting aspect is that tracing is responsible for the low-severity log spam in web builds and log is responsible for the low-severity log spam in native builds

#

i don't remember why

#

it is maybe an unnecessary detail to include in the comments

#

or at least confusing without an explanation

toxic quartz
#

I see. So maybe context would be, "tracing can cause unwanted low-severity log spam in web builds" or the like

#

though tbh it probably would be unwanted in any release build

near mist
toxic quartz
#

interesting, Jan seems to be saying it'd be beneficial to disable tracing in debug too 🤔

near mist
near mist
toxic quartz
#

ah, of course

near mist
#

word overload

toxic quartz
#

how 'bout just:

# Set max static log levels to `debug` by default, and `warn` for release builds. This helps avoid
# unwanted low-severity log spam.
log = { version = "0.4", features = [
    "max_level_debug",
    "release_max_level_warn",
] }
tracing = { version = "0.1", features = [
    "max_level_debug",
    "release_max_level_warn",
] }
#

possibly with a "which can affect performance"

near mist
#

i'd say specifying the debug by default and warn for release builds is redundant since you can see those specifics by reading the following lines anyways

toxic quartz
#

fair enough!

near mist
#

ah yeah

#

i should bump that to 0.15

toxic quartz
#

did you ever figure out what to do with the ChildBuild stuff?

near mist
#

nope i haven't given it any thought

#

the current code works it's just a little ugly

toxic quartz
#

yeah, it's possible the whole spawning bit might change anyway

foggy basin
royal void
#

That's a good PR. I don't have time to test it myself on various workspaces to make sure it works as intended, but it looks good to me.

#

I think that it's not too big

dusky onyx
foggy basin
#

Awesome, thanks!

#

Oh I also just noticed there are merge conflicts now, Ill resolve them asap

foggy basin
#

Conflicts resolved!

pale viper
#

I'll take a look today or tomorrow :)

pale viper
#

I've done a bit more work on the contributing guide for the linter! It now has more content than the release checklist, as well as a plethora of additional resources linked. Check it out!

rocky oxide
#

😄

limber wedge
#

But it showed me even more that i definitely need to step up my documentation game😅

pale viper
pale viper
#

Mainly: The rust compiler has poor API docs, the people reviewing and contributing are almost always unfamiliar with the code, and I’m trying to make the linter as maintainable as possible

#

I want the linter to be a community project, not a pet project, so that should I move on or become too busy it doesn’t stagnate

#

We’re not there yet, but it is a goal I have in mind! :)

limber wedge
limber wedge
#

error: Mismatching versions of `bevy` found, expected crate to be using bevy version: 0.14.2 --> Cargo.toml:9:11 | 9 | avian2d = "0.1.2" | ^^^^^^^ | = note: `#[deny(bevy::duplicate_bevy_dependencies)]` on by default Not sure what the best lint message should be that gives enough information without being confusing, what is your opinion?

pale viper
#

Add a note to the main span, saying the incompatible version of Bevy being pulled in

#

Then add a help message saying the expected version

#

Optionally, you could also add a span to the help message pointing to where the bevy crate's version was originally defined

# 
error: Mismatching versions of `bevy` found
 --> Cargo.toml:9:11
  |
9 | avian2d = "0.1.2"
  |           ^^^^^^^ Note: `avian2d` depends on `bevy` 0.14.2
 Help: Expected all crates to use `bevy` 0.15.0
  |
7 | bevy = "0.15.0"
  |        ^^^^^^^^

(please ignore the poor formatting 🙃)

limber wedge
sturdy tapir
snow linden
#

Are y’all using a custom error/report type or anyhow/erye/whatever?

limber wedge
pale viper
limber wedge
pale viper
#

I could see that getting weird quickly though, VersionReq does implement PartialEq and Eq

#

What problem are you running into, specifically?

limber wedge
#

my problem is, i get a Vec<VersionReq> of crates that use bevy from cargo:metadata. Now i need to decide if these versions match or not. As you mentioned they do implement Eq and PartialEq so checking if they are the same VersionReq is easy but seems like it will often lead to false positives.

limber wedge
pale viper
#

Hmmm, that's tricky

#

I'm not sure how much it applies to your situation, but Cargo.lock contains the resolved versions of all crates

limber wedge
#

yea was searching for a "resolve" method in the semver docs ferris_sob would be so nice. I will check the resolved crates tomorrow iirc they should be part of cargo metadatas output

dull tinsel
#

@pale viper do you happens to know how to use rustc_interface::run_compiler to compile crates including dependencies? I'm currently using this config but I can't figure how to make rustc create any rlib file so I can pass them to dependent crates as extern.

I have this snippet of my config here. I'm using this to compile recursively through all dependencies. The first crate to get compiled should be the one with no dependencies. In my testing, it did compiled and print out some types but I can't figure why rustc isn't making any file.

pale viper
#

If you want to compile dependencies, you need to override which rustc Cargo uses

#

bevy_lint does this by separating into two executables: bevy_lint, which acts like cargo check, and bevy_lint_driver, which acts like rustc

#

To override the rustc that Cargo uses, set the RUSTC_WORKSPACE_WRAPPER environmental variables to the path to your custom rustc

#

Then anytime Cargo needs rustc, it'll run your_executable rustc --actual --arguments

dull tinsel
#

Thanks, for the explanation.
Though Isn’t cargo just a wrapper over rustc? I’ve seen people says that quite often. Running cargo build -v also shows exactly what rustc commands it uses. I’m curious how to does like what cargo does.

pale viper
#

Yes, but Cargo manages building all of your dependencies into rlibs before it compiles your actual crates

dull tinsel
#

Alright thanks, Ill come back to this tmr.

pale viper
pale viper
lapis scroll
#

Awesome! I’ll try to merge it either tonight or tomorrow when I have a chance!

dull tinsel
#

running rustc as a command itself seems to do something at least

dull tinsel
#

oooh wait

#

i think i get it now

#

rustc_interface is only used for interfacing but not a direct rustc command replacement

#

I have to use rustc directly to actually get stuff to compile. that's probably why running commands from the result of cargo --verbose works but through rustc_interface didn't. Those output options is a scam.

#

Also, you guys might want to consider adding configuration for running cargo without using toolchain proxy for folks who installed cargo and other components without using rustup, eg. via nix.

pale viper
pale viper
limber wedge
pale viper
lusty galleon
#

👋 Hi, haven't been following here. What's the status of

Out-of-the-box support for bundling projects into WebAssembly
Any design work done already? Anything I can help with?

limber wedge
#

Im not that familiar with Wasm but i think the bevy build command supports this

foggy basin
lusty galleon
limber wedge
#

Im playing around a bit with ui tests for cargo lints.. does someone know how i can get rid of the --edition flag? ```rs
fn run_ui_cargo() -> color_eyre::Result<()> {
let mut config = Config {
host: Some(String::new()),
program: CommandBuilder {
program: "bevy_lint".into(),
args: vec![],
out_dir_flag: None,
input_file_flag: None,
envs: Vec::new(),
cfg_flag: None,
},
..Config::rustc(Path::new("tests").join("ui-cargo"))
};

config.program.input_file_flag = CommandBuilder::cargo().input_file_flag;

ui_test::run_tests_generic(
    vec![config],
    |path, config| {
        path.ends_with("Cargo.toml")
            .then(|| ui_test::default_any_file_filter(path, config))
    },
    |_config, _file_contents| {},
    status_emitter::Text::from(ui_test::Format::Pretty),
)

}

GitHub
rust-clippy/tests/compile-test.rs at master · rust-lang/rust-clippy

A bunch of lints to catch common mistakes and improve your Rust code. Book: https://doc.rust-lang.org/clippy/ - rust-lang/rust-clippy

#

output: ```FAILED TEST: tests/ui-cargo/duplicate_bevy_dependencies/fail/Cargo.toml
command: "bevy_lint" "--manifest-path" "tests/ui-cargo/duplicate_bevy_dependencies/fail/Cargo.toml" "--edition" "2021"

limber wedge
# 
config.comment_defaults.base().custom.clear();
``` does the trick
foggy basin
#

I've opened https://github.com/TheBevyFlock/bevy_cli/pull/195, which adds the --bundle option to bevy build and bevy run.
It will create a folder with all things needed to deploy the web app, placing it in the target folder (for easy cleanup).
@lusty galleon can you take a look if this is what you had in mind and maybe test it on a real-world project if you have one?

lusty galleon
# foggy basin I've opened <https://github.com/TheBevyFlock/bevy_cli/pull/195>, which adds the ...

Is there some particular project structure that's being assumed? Seeing this output:

 bevy build web --bundle
Compiling to WebAssembly...
    Finished `dev` profile [optimized + debuginfo] target(s) in 0.16s
Bundling JavaScript bindings...
Error: No such file or directory (os error 2)

Attempted tossing my index.html in ./web/, ./assets/web/, and ./, but same output.

(project is https://github.com/rparrett/pixie_wrangler, building on macos)

foggy basin
lusty galleon
#

bevy run web did work (after removing custom canvas and the various custom index.html I flung around above)

foggy basin
#

FYI, in your case you can probably just remove your index.html, we will provide a default one which also adds a loading screen

lusty galleon
#

Yeah, I don't think this particular project needs a custom index.html.

foggy basin
#

But I'll still try to fix your current setup, maybe I missed to consider something

foggy basin
lusty galleon
lusty galleon
#

I think that some feedback for the cli user around what is going on with the "custom web" directory would be helpful. Just a "No web directory found, creating default content" or whatever.

foggy basin
lusty galleon
#

IMO being able to toggle wasm-opt and also override the args used for optimization would be nice. I don't think the options are one-size-fits-all, there are tradeoffs.

#

(but bevy_new_2d's setting is a good default)

pale viper
foggy basin
#

I assume at some point we will want to add a bevy.toml that allows for more customization, without having to define very long arguments every time

foggy basin
foggy basin
pale viper
#

That's the approach I'm leaning towards with the linter

limber wedge
pale viper
foggy basin
#

Merry Christmas!
I opened a PR with which we use custom default profiles for the web builds.
This allows us to use better default configurations and makes it easier for the user to customize it :)
https://github.com/TheBevyFlock/bevy_cli/pull/199

foggy basin
#

@pale viper I think a github milestone for the MVP of the web features (i.e. bevy build web and bevy run web) would be useful to track what still needs to be done.
Afterwards, I would announce the progress more prominently here on Discord to find more people to test everything.
What do you think?

#

I guess a project would also work, not sure which is better

pale viper
#

Would you prefer I scope it specifically to the web features, or would you rather keep it general?

pale viper
foggy basin
limber wedge
foggy basin
limber wedge
#

Yes yes that’s for sure!

foggy basin
#

I'm definitely looking forward to make the CLI official though!
Especially for game jams I think it will make a big difference, enabling everyone to test their game in the browser from the start

#

In other news, I opened https://github.com/TheBevyFlock/bevy_cli/pull/206, which adds a feature flag to run wasm-opt on the binary in release mode.
Once all open PRs are merged, we should be ready to procede with the migration to Bevy CLI in the 2d template

limber wedge
#

Yes i think so too! Im very excited to see where it goes

limber wedge
#

I would start working on this after New Year's: https://github.com/TheBevyFlock/bevy_cli/issues/138. If the linter would get blessed, could we add annotations to bevy that helps autogenerate these: https://github.com/TheBevyFlock/bevy_cli/blob/main/bevy_lint/src/paths.rs ?

GitHub
Support linting multiple versions of Bevy · Issue #138 · TheBevyFlo...

The linter should support being configured for a specific version of Bevy, likely through some form of configuration (#113). It could also be feature-flagged, though that could become quite rigid.

GitHub
bevy_cli/bevy_lint/src/paths.rs at main · TheBevyFlock/bevy_cli

A Bevy CLI tool and linter. Contribute to TheBevyFlock/bevy_cli development by creating an account on GitHub.

pale viper
#

Then lints can do something like:

let is_past_0_14 = with_config(|config| {
  VersionReq::parse("^0.14.0").unwrap().matches(config.bevy_version)
});
#

Hard-coded paths will probably need to be switched to a HashMap or BTreeMap, so we can dynamically adjust them based on the Bevy version

#

More-specifically, the linter should probably be blessed and upstreamed before we begin making changes to the engine for our own benefit

limber wedge
limber wedge
limber wedge
pale viper
limber wedge
#

I see that in the linter this is often used with a similar comment above it

let src_ty = cx.typeck_results().expr_ty(src).peel_refs();

do we want to move it into a helper function in src/utils/hir_parse.rs?
something like ```rs
fn get_src_type(cx: &LateContext<'tcx>, src: &Expr<'tcx>, peel_refs: bool) -> Ty<'tcx>

pale viper
#

If getting the type of an expression was more complicated, I may be convinced, but in my opinion it’s not worth it for a single line of code

limber wedge
#

makes sense yea, it would have been more to avoid having to document the same thing multiple times. But perhaps its enough that its already explained in how-to/types.md

pale viper
#

Yeah, it’s good for people to learn how to use LateContext and TyCtxt directly, instead of hiding it behind too many layers of abstraction

foggy basin
#

Happy new year, let's make it the year of Bevy CLI :)

limber wedge
#

Happy new year!🎆 Thank you for all your hard work and support!

pale viper
#

Let’s goooo! With the new year, we should have some goal for when the CLI and linter get blessed

#

Maybe say we want to have them in a good working state by June, for instance

#

Then we can plan and schedule what needs to be done!

#

The biggest way to get blessed is through actual user adoption. With the CLI, that can be done by adding it to popular Bevy templates

#

For the linter, it could also be added to templates, but I also want to introduce it to the main engine’s CI

limber wedge
#

I think for the linter 0.2.0 is very important!

limber wedge
pale viper
#

@molten merlin maybe you’d be interested in covering a tutorial on using the CLI and linter, once they hit their next release? Only if you think they’re good tools, though, I don’t want to pressure you!

foggy basin
#

I think the next step for the CLI will be to just announce all the new features on #showcase.
And we are getting quite close to do that IMO, the web functionality has come quite far.
If users think he features are good, adoption will follow naturally.
For the future/bigger features we will probably also need a bit more formal discussion with the broader Bevy community, I've seen some complaints that our working group is a bit less formal and doesn't have a full design document etc :D

molten merlin
foggy basin
molten merlin
foggy basin
#

Adding more user facing documentation (or rather, adding some at all) is going to be my next priority

foggy basin
#

(And I'm not 100% sure if that still applies, @pale viper will be able to clarify)

foggy basin
limber wedge
pale viper
#

The two are installed separately, but are designed to play nice together

limber wedge
foggy basin
#

True, design docs for the other features would also be useful!

odd carbon
foggy basin
odd carbon
#

Is bevy_cli designed to work in a CI environment? Either I'm missing some flag, or it's not supported atm 🤔

https://github.com/vladbat00/bevy_egui/actions/runs/12620032025/job/35165252825

Run bevy build --example color_test web --bundle
  bevy build --example color_test web --bundle
  shell: /usr/bin/bash -e {0}
  env:
    CARGO_HOME: /home/runner/.cargo
    CARGO_INCREMENTAL: 0
    CARGO_TERM_COLOR: always
    CACHE_ON_FAILURE: true
Error: IO error: not a terminal
Caused by:
    not a terminal
#

oh I guess it's trying to prompt for wasm-bindgen install or smth?..

#

oh, I'll try it with the --yes flag

limber wedge
odd carbon
#

worked flawlessly, thank you! 😊

love how the bundle command works, really just 1 command, zero configuration - and it's ready for deployment. Got all my crate's examples on github pages now :)
https://vladbat00.github.io/bevy_egui/ui/

foggy basin
#

Glad that it works well for you!
I suppose we should improve the error message in CI, hinting to the --yes flag

pale viper
#

Hopefully we'll be able to re-introduce 0.14 support, but for now it's just 0.15 :)

limber wedge
snow linden
#

what's the status of this? can i just point this at a bevy repo and have it work?

foggy basin
molten merlin
#

I tried running bevy_cli new and got this message, which could probably use an explanation if its going to request to run

screenshot-2025-01-07-at-16.29.522x.png
#

bevy build currently prints an error about reserved profile names after initializing a project with bevy new

screenshot-2025-01-07-at-16.34.352x.png
foggy basin
pale viper
#

@limber wedge Sorry for the delay reviewing #185! I have finals this week(end), but I'll review it in full by the end of next week :)

limber wedge
#

No worries! I also have finals this month so i dont have much time :(

#

Good luck to you!!!!

#

(But i cant wait to get back im so excited to continue working on the linter) stupid university ferris_sob

pale viper
lusty galleon
#

Hm, would it be possible to lint for transforms with scale = 0?

rocky oxide
#

Certainly for the easy cases

#

Might be better as a runtime check though 🤔

slim pine
#

some animations and things might want to shrink objects to a scale of zero (for e.g. a vanishing animation), or even have objects smoothly changing between positive and negative scale for a kind of mirroring effect

#

I probably wouldn't have a runtime warning for that, even if these cases are niche

sturdy tapir
pale viper
#

I opened two new linter PRs! #215, which bumps the nightly toolchain we use, and #216, which adds support for extra fields in delare_bevy_lint!

sturdy tapir
#

What all Lint's are currently in the linter?
I tried finding a list but couldn't

limber wedge
sturdy tapir
pale viper
sturdy tapir
molten merlin
rocky oxide
molten merlin
#

thanks!

foggy basin
sturdy tapir
#

Lint to favor println! over print!
yea.. Made that mistake and gave me hell of a headache.

#

print! Doesn't work in anything till you close the app

foggy basin
toxic quartz
# molten merlin thanks!

Sorry Chris, I should have been keeping a closer eye on this. We should probably also update bevy_new_2d by merging @near mist ' PR although I know there was some discussion around the ChildBuild stuff.

GitHub
Update to bevy 0.15 by benfrankel · Pull Request #318 · TheBevyFloc...

Fixes #320.
We'll probably want to set up a tag / versioning system soon.
The ChildBuild workaround I chose is probably not ideal, but it works.
Confirmed that the game compiles, runs, and ...

#

it's still an incredibly convenient resource to refer people to for e.g. fn plugins, project structure etc.

molten merlin
molten merlin
foggy basin
molten merlin
#

cli generally is now working for me with 0.15 in the minimal template and the newest dev/debug fix

foggy basin
foggy basin
molten merlin
limber wedge
#

do we have some sort of watch already?

molten merlin
#

actually, would be nice to be able to dump the current index.html to a file

foggy basin
molten merlin
#

sure, but building the entire application to write out an index.html file so I can customize it is not really a great solution

foggy basin
foggy basin
limber wedge
molten merlin
foggy basin
near mist
toxic quartz
#

tyty

near mist
#

i changed the rules temporarily to merge this since it has an approving review from @toxic quartz and the update to 0.15 is overdue anyways

pale viper
#

Are there some logging shenanigans that I'm unaware of?

trail shale
#

print!() doesn't clear the buffer, so nothing get displayed until the buffer is cleared. the easiest way to do that is to print a \n, which println!() does

#

but if you want to get into details, there should be a lint against both print!() and println!() because they will both destroy your performances as they perform blocking io

pale viper
#

Should the lint recommend using tracing's macros instead, such as info!()?

trail shale
#

yup!

#

that's one of the main reason to use a log backends instead of just printing, it buffers the write, and often does them in another thread

sturdy tapir
limber wedge
limber wedge
#

Based on the discussion is this something of value or rather not since it „should go away“ at one point or another?

rocky oxide
#

I think a pair of style lints for both ..default and Default::default are very reasonable

vast vine
sturdy tapir
rocky oxide
#

Just to enforce consistency

limber wedge
pale viper
foggy basin
foggy basin
# foggy basin I started a design document so we can more formally discuss the web functionalit...

I'd also appreciate more feedback on the web design document.
Should we create one unified design doc on the whole CLI instead, as @limber wedge suggested? Or would that become too big / to hard to gather feedback on?
Is there anything about the proposed design / vision that I could improve?
When should we move forward to "release" this as a Bevy discussion to get feedback from the broader community?

limber wedge
#

i don't necessarily mean one unified doc but i think we are not doing the template functionality and other ideas justice if we don't also give them a space. i don't know how you do it for bevy normally but i imagine a top level document for the cli and then just sub categories (maybe as a link to another document) for the specific bigger features like the web stuff?

limber wedge
foggy basin
# limber wedge i don't necessarily mean one unified doc but i think we are not doing the templa...

Yea, definitely agree we need something unified.
For the template functionality we also don't have a brief user introduction in the README yet.
For the design doc it's a little difficult, because I assume we want target feedback about specific topics.
Since the topics are so big individually, the discussion around all of them together could get messy.
But I like one unified doc which serves as "entry point" and then e.g. linting and the web stuff being separate documents that are linked to

foggy basin
#

Opened a PR to support cargo's --config argument, which (essentially) allows you to modify Cargo.toml without editing the file:
https://github.com/TheBevyFlock/bevy_cli/pull/209
We can use this to find the best default web compilation profiles for Bevy without much hassle!

limber wedge
foggy basin
#

@limber wedge are you DaAlbrecht on GitHub? What's the status on your two lint PRs, shall I review them or is there anything else needed to be done?

limber wedge
#

To be fair the other one could use a review too. The cargo lint is just more complex but maybe if you could give a hint why CI is failing would be nice!

foggy basin
limber wedge
#

What do you think about switching to a logging crate after 0.1.0?

foggy basin
limber wedge
#

Yes or verbose mode

foggy basin
#

It will also help us to make our output messages more consistent and make them prettier

#

Feel free to create an issue for it!

limber wedge
limber wedge
limber wedge
#

Do you have a strong opinion on what logging crate to use? I think it makes sense if we just use what bevy uses already i.g tracing?

limber wedge
foggy basin
foggy basin
limber wedge
#

not familiar with itch.io but maybe an publish command would be cool for jams?

foggy basin
limber wedge
#

yes! i can add a comment on the HackMD doc aswell

limber wedge
#

we are pretty close to 0.1.0 makes me very happy!

foggy basin
foggy basin
limber wedge
#

o thanks!! 33 will take a look tomorrow

foggy basin
#

I think my next goal will be to work on the web auto reload and then to try and make it work with bacon. I think we might even be able to integrage bacon directly inside the CLI for a bevy watch implementation, but I'll have to experiment with it first

pale viper
#

I'm close to finishing a system to configure the linter through Cargo.toml, which is on the linter-config branch!

#

This is one of the last blockers preventing us from using the linter in Bevy's own CI, which is pretty exciting!

#

Once I finish, you should be able to configure lints like this:

[package.metadata.bevy_lint]
lint_name = "warn"
other_lint = { level = "deny", further-config = true }
#

Internally it uses the new declare_bevy_lint_pass! macro, with the @config extension:

declare_bevy_lint_pass! {
  pub LintPassName => [LINT_NAME.lint],
  @config "lint_name" = {
    further_config: bool
  },
}
foggy basin
#

@pale viper Could you potentially expand the CLI readme with a basic explanation of the linting, similar to the web stuff? I think we will need that for the 0.1 release :)

#

For the templating with bevy new we will also need a section. I can't remember who spearheaded that command

pale viper
#

Totally! I believe @dreamy yacht originally wrote the bevy new command, with @toxic quartz stepping in a little later, but no pressure towards either of them

foggy basin
foggy basin
pale viper
#

What format do you want my section in the README.md to be?

#

Right now it just talks about the web-specific features of bevy {build,run}, but not much else

#

(Specifically, what should the heading be named? Where should I put it? How format / specific should it be?)

foggy basin
#

You can probably come up with better heading names though, writing is not my strength 😅

molten merlin
sturdy tapir
#

Would we like to have a recommened keyboard input handling lint?
like using run conditions instead of using a if at the start of your system?

image.png image.png
rocky oxide
#

I'm not convinced that either of them is bad

sturdy tapir
# rocky oxide Too opinionated IMO

Its more just a question of "what's the standard way to do xyz"
I see a lot of people ask stuff just looking for the standard method people use, and they get frustrated when you hand em 5 ways to do the same thing yknow?
Its like with Godot offering the slide fn just to simplify movement physics. Its not the best way just the common way.

rocky oxide
#

Standard way should be using actions, not raw inputs >.>

sturdy tapir
rocky oxide
#

That's because I haven't upstreamed LWIM yet T_T

sturdy tapir
#

Yea someday

sturdy tapir
# rocky oxide Too opinionated IMO

But yea, I think a category of opinionated lints based off whats common practice is a good idea, sorta like how caseing of fns is opinionated for common practice.

#

Maybe not on by default but available

rocky oxide
#

I definitely agree with that 🙂

sturdy tapir
near mist
molten merlin
near mist
#

Yeah

#

Assuming they just generate and push

molten merlin
#

it has a workflows directory, but nothing in it

near mist
#

Hm I guess that hasn't been added yet to bevy_new_minimal

#

I don't recall what the plan was

#

The --locked issue may have been hit in bevy_new_2d then

#

Yeah bevy_new_minimal only has a ci-generate.yaml for now, which tests that cargo generate works as expected, but no ci.yaml yet

molten merlin
limber wedge
limber wedge
limber wedge
foggy basin
foggy basin
#

@pale viper @limber wedge How do you feel about the current v0.1.0 milestone, is anything not tracked yet?
How exactly do we want to go about the release once it's complete, I assume a maintainer has to approve it first or something like that?

GitHub
`bevy_cli` 0.1.0 Milestone · TheBevyFlock/bevy_cli

A Bevy CLI tool and linter. Contribute to TheBevyFlock/bevy_cli development by creating an account on GitHub.

limber wedge
#

After double checking the issues again the only thing that i would either like to close or add to the milestone is https://github.com/TheBevyFlock/bevy_cli/issues/13. Imo we can close the issue once https://github.com/TheBevyFlock/bevy_cli/issues/221 is merged. What i think is also very important is that we really check the templates that TheBevyFlock provides. I think Chris ran into some issues / questions that he posted here and i think for an "initial launch" its important that everything is smooth.

GitHub
Issues · TheBevyFlock/bevy_cli

A Bevy CLI tool and linter. Contribute to TheBevyFlock/bevy_cli development by creating an account on GitHub.

GitHub
Add tests for build commands · Issue #221 · TheBevyFlock/bevy_cli

We should add some CI tests which run the bevy build and bevy build web commands to ensure that they work as expected. At minimum, they should assert that the command returns a successful status co...

foggy basin
#

Testing the templates also sounds good to me!

limber wedge
#

maybe after the weekend alice could take a look

foggy basin
limber wedge
foggy basin
limber wedge
#

do you know how its "normally" done? or is there not really a specific way

foggy basin
#

Honestly not sure if they are really "published" ususally. I think mostly it's just linked in the working group and pinned?
But we did it a bit backwards that the design document was very surface level and then we just started experimenting :D
It has been critizised a bit that we didn't provide a more formal design doc yet so I think it makes sense to gather more feedback

#

With something like the CLI which I assume would get used quite a lot, I am prepared for a lot of contrary opinions on some topics, but hopefully the parts that we have built are relatively uncontroversial :)

#

But if there is strong community disagreement on some parts of the current implementation we should definitely change it.
Might be more work at this stage, but definitely worth it to ensure that the CLI can be widely adopted

limber wedge
limber wedge
snow linden
#

The design doc is basically something you sand to the maintainers to get official approval on. It has the same sort of feel as an rfc, except that it is supposed to sort of be built in conjunction with experiments just as you have done.

#

Once you want approval (eg so that this tool becomes official) you can probably just at cart/alice and ask for it.

foggy basin
foggy basin
snow linden
#

You can if you want to. The idea was that a quick approval on a design doc can save people wasting work on an implementation that will get rejected.

#

That might not be applicable here?

foggy basin
# snow linden That might not be applicable here?

Not for the 0.1 work that has already been done, you are right. But there are still several features on the roadmap where it would be useful to get approval first before investing more work on it
I also think it's important to approve of the current prototype first before we release it, to avoid broader adoption of something that will get scrapped or changed significantly. Especially if it were to be included in the 0.16/0.17 release notes

limber wedge
#

Yea i see it as useful to get approval on the prototype first and with that form a doc that focus on the next chunks of work that are on the roadmap.

foggy basin
#

Just remembered I'll also finish porting bevy_new_2d to the Bevy CLI, I think we have everything we need now

foggy basin
#

Made some progress: https://github.com/TheBevyFlock/bevy_new_2d/pull/312
I think it's mostly done now. We mainly need to test the release CI workflow and fix a bug with the audio.
We do ship a script in the CLI that should restart the audio context automatically, but maybe it has a bug right now

near mist
foggy basin
sturdy tapir
#

Why does the bevy_new_2d have the indirection of main just importing a plugin that contains the whole app?

I don't see the purpose

near mist
#

you can write a bin/ script to run bevy_mod_debugdump on the schedule graph created by adding your whole app as a plugin, for example

sturdy tapir
#

then stuff like that should probably be explained in comments
noobs to programming often try to start with game dev and might think that its neccesary to always do that

near mist
#

yeah it probably should be either in comments or docs/design.md

#

preferably the latter imo

sturdy tapir
#

comment duplication wont kill us

near mist
#

yeah it's moreso that the comments in the template shouldn't look like example comments but more like something a user might write in their own project, because the template will become their project

#

if the comment is worded in such a way then yeah both is good

sturdy tapir
#

actually this is a good example of the style of comments
It concisely explains why its being done

image.png
limber wedge
#

@foggy basin I hope this does not come across as disrespectful. Thought it would be less work for you so i left my review and how it could look with the assert_cmd crate here: https://github.com/TheBevyFlock/bevy_cli/pull/247

GitHub
feat: use assert_cmd by DaAlbrecht · Pull Request #247 · TheBevyFlo...

Switch toassert_cmd
rename the dev tests to debug
rename clean_target_binaries to clean_target_artifacts and require the path to be already set to the target instead of joining inside.
Simplify exe...

foggy basin
foggy basin
limber wedge
limber wedge
#

Should this then just be "web" https://github.com/DaAlbrecht/bevy_cli/blob/221-test-build-commands/tests/build.rs#L90 or change this to web-dev

GitHub
bevy_cli/src/external_cli/cargo/mod.rs at 221-test-build-commands ·...

A Bevy CLI tool and linter. Contribute to DaAlbrecht/bevy_cli development by creating an account on GitHub.

GitHub
bevy_cli/tests/build.rs at 221-test-build-commands · DaAlbrecht/bev...

A Bevy CLI tool and linter. Contribute to DaAlbrecht/bevy_cli development by creating an account on GitHub.

foggy basin
pale viper
#

Furthermore: now that #222 is merged, can I close #13? I'm not sure if there was anything else you wanted to do before it's marked as done

foggy basin
foggy basin
pale viper
limber wedge
#

Are you still studying for exams? @pale viper ferris_sob

pale viper
#

If they look good to you, I'll approve #210 and merge it :)

limber wedge
#

Yes i saw yesterday but was so tired after work will take a look once i get home!

limber wedge
pale viper
#

While you do that, I'm going to look over the Cargo lint infrastructure you set up (finally!)

limber wedge
#

Yea that one was a bit more complicated. Interested in your thoughts

foggy basin
vast vine
#

Should we have a lint that warns on Query<Entity>? I feel like that's pretty much never what you'd want unless a very niche use case.

#

I ask because I just saw that in a PR

pale viper
vast vine
#

That's why I suggest a warning

pale viper
#

Are there better alternatives?

vast vine
#

I honestly can't think of a reason where you would need all entities

pale viper
#

Ohhh, you mean just Query<Entity>, not Query<Entity, With<SomeFilter>>

vast vine
#

A warning that can be disabled should allow people to do that if they wish too, but at least it won't happen by mistake

vast vine
#

same for Query<()>

#

which is also technically valid

#

or at least it builds

pale viper
#

That makes a lot more sense! 😅

vast vine
#

Query<(), ()> also seems valid

#

how should I name those? Undefined queries maybe?

pale viper
#

There's any issue for weird queries already, so I'm adding a comment to it now

vast vine
#

I want to say empty, but Query<Entity> is the opposite of empty

vast vine
vast vine
pale viper
vast vine
#

I think it's a bit separate? I mean, it could be the same lint, but I feel like there might be a very niche use case for Query<Entity> but I don't see that for Query<&Foo, With<Foo>>

pale viper
#

Maybe calling Query<Entity> a "bad query" is too harsh, how about "suspicious query"?

#

We already have a SUSPICIOUS category, so it would fit nicely there :)

vast vine
#

Yeah, I guess all of those could be classified as suspicious queries

#

so you could #[allow(suspicious_queries) if you ever need Query<Entity> and that reads better than #[allow(bad_queries)]

pale viper
#

Definitely!

#

I'll update the issue

#

Thanks for the suggestion!

pale viper
#

I made another pass over the linter v0.2.0 milestone. I set a soft deadline for February 15th, with a hard deadline for the end of February. I also pushed quite a few issues onto v0.3.0, since it doesn't look like we'll complete them within that time.

slim pine
#

I'm not necessarily against it, just curious what the value is

vast vine
#

If they use that query for something then I consider it a problem

slim pine
#

🤔 Okay fair I guess

vast vine
#

At least, a performance problem

pale viper
limber wedge
foggy basin
#

Hmm, so with the Bevy CLI port for bevy_new_2d I had the issue that I didn't get any audio, along with the warning "An AudioContext was prevented from starting automatically. It must be created or resumed after a user gesture on the page."
But also a user gesture doesn't fix it.
However, I just tested on main with trunk as we had before, but I get the same issue. Did something break when updating to Bevy 0.15? Does anyone know what the issue may be?

#

Ah nevermind, looks like the main version works now. Seems like the Bevy CLI doesn't find any audio contexts to resume, I'll look into it

foggy basin
pale viper
#

I've been noticing that CI has become significantly slower (~1 hour 😱) after the end-to-end tests added in #222. To share dependencies, could we make them use the main target folder instead of tests/bevy_cli_test/target?

#

I'm not against E2E testing in the slightest, but I definitely would prefer the 5 minute times we had previously 😆

limber wedge
#

i thought this is just the case because for the e2e tests we remove most artefacts but the insane long ci time is really annoying

#

didnt know that putting them into the main target folder would improve that sorry

pale viper
#

Nah, you're good! Just removing the generated executable shouldn't cause such significant slowdowns, since usually it takes far more time to build the dependencies

#

As a fun fact, check out the contents of target/debug next time you're working on a Rust project! target/debug/deps contains the object files for the built dependencies, target/debug/build contains build.rs output, and target/debug/.fingerprint is used to Cargo to track when things need to be rebuilt

limber wedge
limber wedge
foggy basin
pale viper
pale viper
rigid bluff
#

Hello you fine people, I don't know if it's possible but have you thought about adding a cli command to add a new plugin crate to a project ?

foggy basin
#

What exactly do you mean? Adding a new crate to the current workspace which contains a scaffold vor a Bevy plugin?

#

I definitely thought about adding a template for a Bevy library, which would include a basic plugin scaffold and Bevy without default features as dependency.
For the command you proposed, I assume it would be harder because of different workspace setups, I don't know how we could determine in which folder to put the crate

foggy basin
#

(well, it's still slower than before the E2E tests, but only 20 min instead of 1 hour now)

rigid bluff
# foggy basin What exactly do you mean? Adding a new crate to the current workspace which cont...

I agree I wasn't very clear.

When I need to create a new plugin I need to make a new folder, import bevy prelude, then add the plugin declaration and impl.

This could be simplified to something like bevy plugin game/tree

That would create a file src/game/tree/mod.rs
containing

use bevy::prelude::*;

pub struct TreePlugin;

impl Plugin for TreePlugin{
    fn build(&self, app: &mut App) {}
}

It could even maybe set it up as a completely standalone crate with a .toml and everything (I don't usually do that BECAUSE of the boilerplate even though there are tons of pros of doing it this way).

I'm not a pro in rust workspaces so I might be wrong about some things.

I just thought about it because it felt like something I spend a lot of time doing when it could be automatic.

pale viper
#

I’m not sure about a custom subcommand yet, I’d rather we reach a consensus from the community / maintainers before going in a specific direction like that

rigid bluff
pale viper
#

I find they’re easy enough to make yourself, but I do think there may be a few Bevy plugins out there that you could try!

limber wedge
#

I tend towards snippets too. I personally just use the lsp impl command and it at least generates fn build(&self, app: &mut App)

versed sparrow
#

in bevy_lint/docs/howto/README.me, the Tutorials hyperlink goes no where

limber wedge
#

But we should probably remove it

versed sparrow
#

Gotcha

#

I'm interested in working a bit on the linter. Just reading thru the conversation here and next the changelogs

limber wedge
#

I can recommend the rustc section highlighted in the readme a lot!

near mist
#

it doesn't include one for a struct plugin like you wanted, because of the convention in bevy_new_2d to mainly use fn plugins

#

but it's easy to add

sturdy tapir
foggy basin
#

I opened a PR which causes the browser tab to reload when bevy run web restarts:
https://github.com/TheBevyFlock/bevy_cli/pull/256

This will (probably) enable us to fake a bevy watch web with bacon already.
It also sets up the infrastructure for cold and eventually hot asset reloading for Bevy web apps!

limber wedge
#

Im sorry that you need to review two „big“ pr‘s ferris_sob @pale viper will clean up the bevy duplicate version lint a bit more / fix merge conflicts

molten merlin
#

what is the relationship between bevy lint and cargo clippy? I see some overlapping warnings and some unique

rocky oxide
molten merlin
#

ok good to know, I'm seeing unused_variables, etc from bevy_lint right now. I think its 0.1 (not main) but there doesn't seem to be a --version option for bevy_lint either.

screenshot-2025-02-02-at-16.35.522x.png
sturdy tapir
#

Do we already have a lint to override the normal "too many arguments" lint? Because systems can get pretty big and I get tired of adding the allow to every other system

molten merlin
#

the templates the cli uses by default set it there

limber wedge
foggy basin
#

Does anyone know the difference between debug = false and strip = "debuginfo" in the profile configuration?
I'm thinking whether we should disable or limit debuginfo in the default wasm dev profile, as I think it could greatly reduce iteration times (as it will also speed up bundling and loading)

limber wedge
foggy basin
limber wedge
#

Hahahaa yea i didn’t fully get it either. How I understood it is that with debug=false you could not use a debugger if you want to and no backtraces. While with strip both should be most likely still possible ferris_sob

#

So i would tend towards strip?

foggy basin
#

Yea we'll also have to see what type of debug info is even usable on wasm

pale viper
#

bevy_lint also does not currently support multiple versions of Bevy. v0.1.0 supports Bevy 0.14, and the main branch supports Bevy 0.15

#

Eventually there will be configuration to select which version you want (issue), but it's not been started yet

foggy basin
limber wedge
foggy basin
limber wedge
#

Hahah yes!!!!!

limber wedge
#

what are the next steps for the CLI? I think the milestone can be completed. Do you want to release 0.1.0 together with the linter 0.2.0?

foggy basin
# limber wedge what are the next steps for the CLI? I think the milestone can be completed. Do ...

From my perspective:

  • Updating the overarching CLI design doc with the individual parts (e.g. the new web design doc)
  • Finishing the port of the templates to the Bevy CLI (I think for the minimal template we need to create a PR, for the 2d one we just need a review I think (and fix any potential CI errors on the release pipeline)
  • Lots of testing!
  • Getting approval from a maintainer about the current prototype and the visions in the design doc
  • Release!
#

And then after 0.1.0 my main focus will be (a) aiding with the experimental multi threading feature (b) exploring asset hot reloading for web builds

versed sparrow
#

Are overlapping queries linted ? Systems with query params that conflict with eachother and cause a panic ?

limber wedge
versed sparrow
#

I read "- Lints panicking_query_methods and panicking_world_methods" in CHANGELOG and it looks like they just lint single vs get_single stuff

limber wedge
versed sparrow
#

Is it within scope of things we would want to be linted ?

limber wedge
#

Hm not sure how possible that lint even would be.

pale viper
#

Right now we're focused on footguns that cannot be caught as easily, though this is definitely on the table a little later on!

versed sparrow
#

Yeah I guess the panic instantly, right after compilation

versed sparrow
pale viper
versed sparrow
#

Ahh thanks, I see lints that people have actually been asking for now

#

Can someone explain the tests for bevy_lint ? I don't really understand it

#

I've only written very basic tests myself

pale viper
pale viper
#

So instead of this, we have UI tests. These are tests that feed the linter a Rust program and verifies that certain warnings / errors are emitted

versed sparrow
#

Aah okay, so the UI is kind of capturing the output of that compilation of the RUst program ?

pale viper
#

We use ui_test for this, which is a crate that facilitates UI tests. It also happens to be used by Clippy, Miri, and maybe the Rust compiler!

pale viper
versed sparrow
#

Lol what a unique problem

pale viper
# 
fn main() {
    //~^ HELP: try
    App::new().run();
    //~^ ERROR: an entrypoint that calls `App::run()` does not return `AppExit`
}
#

The //^ ERROR comment tell ui_test that an error diagnostic should be emitted on the line above it

#

You can also look at main.stderr, which stores a copy of the diagnostic emitted!

versed sparrow
#

Ah okay. I suspect I can learn more about this just reading ui_test ?

pale viper
#

Yup, though the docs aren't too in-depth for ui_test. I believe the rustc dev guide may have more information as well...

versed sparrow
#

Oh i've never been to lib.rs before. very unfamiliar with this ui

pale viper
pale viper
versed sparrow
#

Cool

pale viper
#

This vulnerability is unlikely to ever be exploited with the bevy_cli, but the change was so simple (cargo update) that I figured it would be fine

#

And don't worry, I'm still going through #185, it's just a little bit larger

image.png
limber wedge