RA shows E0308 error rustc doesn't

[PAStheLoD]

rust-analyzer version: 0.3.2769-standalone (2532c48 2026-01-25)

rustc version: 1.93.0 (254b59607 2026-01-19)

editor or extension: VSCode 0.3.2769 (Windows 11)

relevant settings: N/A

repository link (if public, optional): https://github.com/tauri-apps/muda/ 0.17.1

code snippet to reproduce:

use muda::{Menu, Submenu};

fn main() {
let menu_bar = Menu::new();
let file_m = Submenu::new("&File", true);

menu_bar.append_items(&[&file_m]).ok();
//                    ^^^^^^^^^^
// expected &[&(dyn IsMenuItem + 'static)], found &[{unknown}; 1]
// expected &(dyn IsMenuItem + 'static), found &Submenu
// rust-analyzer E0308
}

Hello,

I tried to understand where this warning might be coming from (to get some sensible minimal reproduction), but cargo check doesn't show any warnings, and programs with all kinds of these strange coercion errors run without runtime errors.

The same (or something similar) happens with using Dioxus 0.7.3 desktop feature,

use dioxus::prelude::*;

// but Element is Result<VNode, RenderError>
// VNode is a struct with an Rc


// rsx!  is a proc macro

fn popup() -> Element {
    rsx! {
        div { "This is a popup window!" }
        // ^
        // expected &[TemplateNode], found &[TemplateNode; 1]
        // rust-analyzer E0308
    }
}

I tried searching for similar issues on the library repositories too, and via Google. (Only found closed issues like #13864, but that's supposed to be fixed, and here is also a missing 'static bound.)

Thanks for considering!

[ChayimFriedman2]

I fail to reproduce. Can you check if this is still present on latest r-a?

[alexyarovoy]

@ChayimFriedman2 I seem to have similar issue with E0308 error for code like:

pub const MY_CONST: &[u8; 16] = include_bytes!("../../../myfile.key");

With error message:
expected &[u8; 16], found &'static [u8; 0]

rust-analyzer version: 0.3.2777-standalone (7cb789d 2026-02-01)
rustc version: rustc 1.93.0 (254b59607 2026-01-19)
editor: Zed and VS Code

Not sure if I need to create a separate issue for this, should I?

[lnicola]

That's a different issue and it's actually by design, we don't want to load possibly huge files like this.

[alexyarovoy]

That's a different issue and it's actually by design, we don't want to load possibly huge files like this.

I've seen an old issue #12181 about a hint. But it didn't show as an error until recently. It seems something changed couple weeks ago related to this error code.

[flodiebold]

That's a different issue and it's actually by design, we don't want to load possibly huge files like this.

Could we get the file size and use that somehow? 🤔

[flodiebold]

That's a different issue and it's actually by design, we don't want to load possibly huge files like this.

I've seen an old issue #12181 about a hint. But it didn't show as an error until recently. It seems something changed couple weeks ago related to this error code.

What changed recently is just that we now show the type errors, which we didn't previously. So yeah, that is just #12181.

[ChayimFriedman2]

But it did became way more severe - we can probably limit the impact by expanding to an error length, but this is not entirely fool-proof.

[ChayimFriedman2]

That's a different issue and it's actually by design, we don't want to load possibly huge files like this.

Could we get the file size and use that somehow? 🤔

We would then need to watch them, so this should at least wait until the VFS rewrite. CC @davidbarsky.