-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Prepare a 2.0.4 Release #3597
Prepare a 2.0.4 Release #3597
Conversation
This commit fixes an issue where out of bound text/binary binds on `sql_query` using the sqlite backend causes a panic in an internal drop impl. It was caused that we pushed to the list of released binds before we actually checked whether that bind was possible or not. This caused us trying to bind to the same invalid bind again in the drop impl, while being on the normal error path. It's fixed by just moving the relevant push after the actual bind. In addition a regression test for this problem is added.
017255d
to
1dd1483
Compare
diesel_derives/src/table.rs
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@adamchalmers Can you remove this file. It shouldn't be here, as the 2.0.x branch uses the macro_rules
based table!
macro.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
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).
1dd1483
to
7a7a7b4
Compare
Hmm, the "Check Minimal support rust version (1.56.0)" action is failing because libsqlite3-sys 0.26 requires 1.58 (because it uses But I don't know why it's even trying version 0.26, because it should use the minimal version. |
Is it possible to pick up #3435 as well? |
Should we release a 2.1 and get everything in? Or are there breaking changes other than bugfixes that I missed? |
This commit fixes an issue where empty owned strings (and `Vec<u8>`) were serialised to null values instead of to just empty values. This happened due to a passing null ptrs to the sqlite API at the wrong location. Also two regression tests are added for this issue.
7a7a7b4
to
c607cf1
Compare
Co-authored-by: Georg Semmler <github@weiznich.de>
60e3eb2
to
2aaaa33
Compare
OK, all tests pass now! |
Thanks for updating the PR. I did not find the time to day to to the release, will try that again tomorrow. |
I've manually merged this to the relevant branch + done the release. |
As suggested in #3594 it might be reasonable to cut a 2.0.4 release to bring the r-a fix faster to our users.
Thanks for @adamchalmers for preparing the branch.
@diesel-rs/core I would like to cut a release on monday if noone as objections.