Skip to content

RunQueryDsl overrides calls to vec.first() to RunQueryDsl::first() #142

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

Closed
3 tasks done
cdxker opened this issue Mar 13, 2024 · 6 comments
Closed
3 tasks done

RunQueryDsl overrides calls to vec.first() to RunQueryDsl::first() #142

cdxker opened this issue Mar 13, 2024 · 6 comments
Labels
enhancement New feature or request

Comments

@cdxker
Copy link

cdxker commented Mar 13, 2024

Setup

RunQueryDsl overrides calls to vec.first to RunQueryDsl::first() this happens to all possible calls to first() if the trait is imported.

Versions

  • Rust:: 1.75
  • Diesel:: 2.1.4
  • Diesel_async:: 0.4.1
  • Database:: None
  • Operating System: EndeavourOS

Feature Flags

  • diesel:: None
  • diesel_async:: None

Problem Description

The diesel_async::RunQueryDsl trait overrides the default behavior of any structs first() function to RunQueryDsl::first causing a nasty compile time error.

What are you trying to accomplish?

I wish to use the vec.first() operation instead of vec.get(0). (Mainly becuase clippy errors, but this is a pretty hard bug to find).

Steps to reproduce

Here is a gist that shows the issue at hand.
https://gist.github.com/fastfists/9d0f1da80f825be39f9a4499aa8990a7

Checklist

  • I have already looked over the issue tracker 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
@cdxker cdxker added the bug Something isn't working label Mar 13, 2024
@weiznich weiznich added enhancement New feature or request and removed bug Something isn't working labels Mar 13, 2024
@weiznich
Copy link
Owner

Thanks for filling this bug report. I've changed it to be tracked as feature request, as it's strictly speaking not a bug. We are happy to receive a PR that improves this as long as it does not break existing code.

@cdxker
Copy link
Author

cdxker commented Mar 13, 2024

I tried reading into it but did not quite understand, how does the trait work at the current moment? Does it try to infer any diesel::QueryDsl functions into diesel_async::RunQueryDsl functions?

@weiznich
Copy link
Owner

The relevant implementation is here:

fn first<'query, 'conn, U>(
self,
conn: &'conn mut Conn,
) -> return_futures::GetResult<'conn, 'query, diesel::dsl::Limit<Self>, Conn, U>
where
U: Send + 'conn,
Conn: AsyncConnection,
Self: diesel::query_dsl::methods::LimitDsl,
diesel::dsl::Limit<Self>: methods::LoadQuery<'query, Conn, U> + Send + 'query,
{
diesel::query_dsl::methods::LimitDsl::limit(self, 1).get_result(conn)
}

That one essentially says that this method is only available for types that implement LimitDsl. That shouldn't be the case for Vec<T>, because that trait is only implemented for diesel query DSL structs. So I'm not sure why rustc believes that this could potentially overlap with the first method from Vec<()>, might be even worth filling an issue for that at the rust repo? (Feel free to ping me from there)

@fiadliel
Copy link

As I understand it, the behavior of method resolution is that for a particular receiver type, the compiler looks first for inherent methods, and if that fails, then it looks for methods provided by visible traits (RunQueryDsl is visible if imported).

One might expect the inherent first method implemented by Vec to be chosen - BUT it is implemented for &Vec, whereas the extension method here is implemented for Vec (because of the self parameter).

As per https://doc.rust-lang.org/reference/expressions/method-call-expr.html, the algorithm is run in order for candidate receiver types, and T (aka Vec) has the highest priority.

@pdtilton
Copy link

For those looking for a workaround you can use: .get(0).

@weiznich
Copy link
Owner

I think this is essentially another duplicate of rust-lang/rust#127306.

Closed as this is an upstream rust bug.

@weiznich weiznich closed this as not planned Won't fix, can't repro, duplicate, stale Aug 30, 2024
eakoli added a commit to eakoli/diesel_async that referenced this issue Feb 5, 2025
This resolves issue weiznich#142

As it more closely matches the Ts that diesel::RunQueryDsl 
is implemented for as opposed to all Ts
eakoli added a commit to eakoli/diesel_async that referenced this issue Feb 10, 2025
This resolves issue weiznich#142

As it more closely matches the Ts that diesel::RunQueryDsl 
is implemented for as opposed to all Ts
eakoli added a commit to eakoli/diesel_async that referenced this issue Feb 11, 2025
This resolves issue weiznich#142

As it more closely matches the Ts that diesel::RunQueryDsl 
is implemented for as opposed to all Ts
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants