Fix type resolution in rust-analyzer

[weiznich]

It turns out that we relay on a type resolution hack for our derives that only work with rust 2015. That's not a problem with rustc, as it uses whatever edition a crate is using. So it will use rust-2015 for name resolution in the expansion of our proc macros, due to the fact that diesel_derives is a edition = 2015 crate. The problem is that rust-analyzer does not understand this, as they use basically the name resolution rules from the 2018 edition. (To be clear that's something that's not "standard" conform there, but it does not seem to be a priority to fix that).
As this affects our core type system (== all the SQL types, …), that has pretty serve effects on what users see in their IDE.

Fortunately the workaround is simple as we just need to use an alternative way to provide an diesel item in diesel itself to make our macros work there. It seems like both rustc and rust-analyzer agree on the extern crate self as diesel; solution.

After this basically all known cases of rust-analyzer issues are gone away (at least as far as I tested).

Before:

After:

[Ten0]

I can confirm this solves part of the issue but not all of the issues are resolved.
Essentially as soon as joins are involved it seems to lose track of the types:

#![allow(unreachable_code, unused)]

use diesel::{prelude::*, table};

table! {
	users {
		id -> Integer,
		name -> Text,
	}
}
table! {
	posts {
		id -> Integer,
		user_id -> Integer,
	}
}
joinable! { posts -> users (user_id) }
allow_tables_to_appear_in_same_query! { posts, users }

fn main() {
	let db: &mut diesel::pg::PgConnection = todo!();

	let p = posts::table.select(posts::id).load::<i32>(db).unwrap();

	let u = users::table
		.inner_join(posts::table)
		.select((users::name, posts::id))
		.load::<(String, i32)>(db)
		.unwrap();
}

gives (with in red the type inferences failing):

I suspect rust-lang/rust-analyzer#9881 may be the cause.

[weiznich]

@Ten0 I fear we cannot do much about the inner join issue, if it's really related to that unimplemented chalk feature. That's then something that needs to be fixed in rust-analyzer/chalk.

[Ten0]

@Ten0 I fear we cannot do much about the inner join issue, if it's really related to that unimplemented chalk feature. That's then something that needs to be fixed in rust-analyzer/chalk.

Yup, was just mentioning it so that we don't spend more time investigating that thinking it was supposed to be fixed 🙂

After this basically all known cases of rust-analyzer issues are gone away (at least as far as I tested).

[ES1993]

rustover ok