Skip to content

Weird mismatched-arg-count lint on gtx_pipeline! macro. #9887

New issue

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

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

Already on GitHub? Sign in to your account

Open
haihala opened this issue Aug 14, 2021 · 7 comments
Open

Weird mismatched-arg-count lint on gtx_pipeline! macro. #9887

haihala opened this issue Aug 14, 2021 · 7 comments
Labels
A-parser parser issues C-bug Category: bug S-actionable Someone could pick this issue up and work on it right now

Comments

@haihala
Copy link

haihala commented Aug 14, 2021

I'm new-ish to rust and don't know if the error is in the code or in the analyzer.

Opening https://github.com/PistonDevelopers/piston-examples/blob/master/examples/cube.rs in vscode makes rust-analyzer complain about mismatched-arg-count on lines 25-32. The exact message is a bit stranger still:

{
	"resource": "<redacted>",
	"owner": "rustc",
	"code": {
		"value": "mismatched-arg-count",
		"target": {
			"$mid": 1,
			"external": "https://rust-analyzer.github.io/manual.html#mismatched-arg-count",
			"path": "/manual.html",
			"scheme": "https",
			"authority": "rust-analyzer.github.io",
			"fragment": "mismatched-arg-count"
		}
	},
	"severity": 8,
	"message": "expected 7 arguments, found 4",
	"source": "rust-analyzer",
	"startLineNumber": 25,
	"startColumn": 1,
	"endLineNumber": 32,
	"endColumn": 4
}

The message says it expects 7 arguments, but found 4. Neither of these numbers make sense in any way I can think of.

Code of the macro:

/// Defines a set of pipeline-associated structures, and also
/// adds `new` constuctor for the `Init` structure.
#[macro_export]
macro_rules! gfx_pipeline {
    ($module:ident {
        $( $field:ident: $ty:ty = $value:expr, )*
    }) => {
        #[allow(missing_docs)]
        pub mod $module {
            #[allow(unused_imports)]
            use super::*;
            #[allow(unused_imports)]
            use super::gfx;
            gfx_pipeline_inner!{ $(
                $field: $ty,
            )*}
            pub fn new() -> Init<'static> {
                Init {
                    $( $field: $value, )*
                }
            }
        }
    }
}

Application of the macro:

gfx_pipeline!( pipe {
    vbuf: gfx::VertexBuffer<Vertex> = (),
    u_model_view_proj: gfx::Global<[[f32; 4]; 4]> = "u_model_view_proj",
    t_color: gfx::TextureSampler<[f32; 4]> = "t_color",
    out_color: gfx::RenderTarget<::gfx::format::Srgba8> = "o_Color",
    out_depth: gfx::DepthTarget<::gfx::format::DepthStencil> =
        gfx::preset::depth::LESS_EQUAL_WRITE,
});
@lnicola
Copy link
Member

lnicola commented Aug 14, 2021

It happens when for some reason (wrong type inference/trait solving, wrong macro expansion, unsupported features like const generics) we pick up the wrong function.

It would really help if you can extract a reduced test case, but it's all right if you can't or don't have the time.

@lnicola lnicola added A-nameres name, path and module resolution A-ty type system / type inference / traits / method resolution S-actionable Someone could pick this issue up and work on it right now labels Aug 14, 2021
@flodiebold
Copy link
Member

flodiebold commented Apr 6, 2022

This is still happening, and really confusing. Here's a small reproduction:

fn foo(s: gfx::TextureSampler<[f32; 4]>) {
    let (a, b, c, d);
    s.bind_to(a, b, c, d);
}

Hovering over bind_to shows

gfx::pso::DataBind

pub fn bind_to(&self, RawDataSet: {error}, _: {error}, _: {error}, _: {error}, _: {error}, AccessInfo: {error}, _: {error})

---

Dump the given data into the raw data set.

but going to the definition shows the following code:

/// The "bind" logic portion of the PSO component.
/// Defines how the user data translates into the raw data set.
pub trait DataBind<R: c::Resources> {
    /// The associated "data" type - a member of the PSO "data" struct.
    type Data;
    /// Dump the given data into the raw data set.
    fn bind_to(&self,
               &mut RawDataSet<R>,
               &Self::Data,
               &mut c::handle::Manager<R>,
               &mut AccessInfo<R>);
}

which clearly takes 4 parameters. I don't understand how we can have two different definitions here.

@Veykril
Copy link
Member

Veykril commented Apr 6, 2022

The reason for that is that we fail to parse the param list properly here. Because of that error recovery kicks in which parses each path segment as a new parameter, so Self::Data becomes two, and c::handle::Manager<R> becomes 3 parameters totalling 8 parameters.

@Veykril Veykril added the A-parser parser issues label Apr 6, 2022
@Veykril
Copy link
Member

Veykril commented Apr 6, 2022

Given anonymous parameters are a hard error since the 2018 edition we could consider this a wontfix if it turns out to be too much work to fix in the parser

@lnicola
Copy link
Member

lnicola commented Apr 6, 2022

If we do end up with a shared parser, we might have to fix this anyway.

@flodiebold
Copy link
Member

Well, it might be a wontfix-until-shared-parser then ;)

@flodiebold flodiebold added C-bug Category: bug and removed A-ty type system / type inference / traits / method resolution A-nameres name, path and module resolution labels Apr 6, 2022
@flodiebold
Copy link
Member

gfx is also kind of deprecated; there are probably few maintained crates that use anonymous parameters.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-parser parser issues C-bug Category: bug S-actionable Someone could pick this issue up and work on it right now
Projects
None yet
Development

No branches or pull requests

4 participants