Derive Queryable deserialize_as attribute doesn't support tuples

[Elrendio]

Setup

Versions

• Rust: rustc 1.75.0 (82e1608df 2023-12-21) (built from a source tarball)
• Diesel: master
• Database: PostgreSQL (but in this case doesn't matter)
• Operating System: NixOS

Feature Flags

• diesel: features = ["postgres", "r2d2", "serde_json", "chrono"]

Problem Description

When using derive macro Queryable attribute deserialize_as with a tuple I get the error expected identifier:

error: expected identifier
   |
   |             deserialize_as = (i32, String),
   |                              ^

What are you trying to accomplish?

Use a tuple with deserialize_as

What is the expected output?

Compiles

What is the actual output?

Doesn't compile

Are you seeing any additional errors?

No

Steps to reproduce

mod schema {
  diesel::table! {
	  my_table (acceptable_loss_flag_id) {
		  id -> Int4,
		  value_1 -> Int4,
		  value_2 -> Varchar,
	  }
  }
}

#[derive(Queryable)]
struct MyStruct {
  id: i32,
  #[diesel(deserialize_as = (i32, String))]
  val: (i32, String),
}

Checklist

• I have already looked over the issue tracker and the discussion forum for similar possible closed issues.

• This issue can be reproduced on Rust's stable channel. (Your issue will be
  closed if this is not the case)
• This issue can be reproduced without requiring a third party crate

[weiznich]

Thanks for opening this bug report. The relevant parsing code for that is here:

diesel/diesel_derives/src/attrs.rs

Line 43 in d3f7099

DeserializeAs(Ident, TypePath),

and here:

diesel/diesel_derives/src/attrs.rs

Line 148 in d3f7099

parse_eq(input, DESERIALIZE_AS_NOTE)?,

I'm happy to accept a PR that extends the parsing code there to allow something else than Ident there, as long as it can demonstrate that it doesn't break existing code.

[Elrendio]

I'm happy to accept a PR that extends the parsing code there to allow something else than Ident there, as long as it can demonstrate that it doesn't break existing code.

I'm not sure the issue is Ident, I think it's the TypePath instead of Type that causes it 😊. It was introduced in this PR (see commit)following this comment.

Do you want me to simply revert or would you like to support only a subset of Type ?

[weiznich]

Thanks for digging that up. I think it should be fine to support all possible Type variants there, although only Tuple, Array, Ptr, TraitObject and maybe BareFn seems to be relevant. I think it wouldn't be that easy to support for example the Reference variances due to lifetimes.

Likely we want the parser to accept all variants and then have a later check that just filters out some of them?

[Elrendio]

Hey 👋

Sorry for the delay

I'm aligned with:

Likely we want the parser to accept all variants and then have a later check that just filters out some of them?

I'll suggest a PR in the coming months 😊