This changes the lint settings to only emit warnings by default. This
means that during development, you'll get to see warnings, but rustc
will continue on with compiling diesel.
When explicitly checking the code for code style (on CI in the clippy
build step, or when using `bin/check`), we supply `--deny warnings` as a
flag to `rustc` to error out on warnings.
This does not change anything when using diesel as a dependency, as
cargo automatically sets all lints to allow in that case.
This is a refactoring in preparation for ad-hoc join clauses. I'm
imagining the API being roughly `lhs.inner_join(rhs.on(on_clause))`,
which will mean we will have a struct containing the rhs and the on
clause. The `JoinTo` impl for this struct will need to just destructure
it and return those pieces, so this sets up the trait changes for all
existing implementations.
I had to bump clippy as part of this change, as it hits a rustc bug that
was fixed on more recent nightlies. However, I couldn't bump to the
*latest* clippy, as recent nightlies are broken for us due to
https://github.com/rust-lang/rust/issues/43153
Clippy has become unhappy with some of the new code. This code is *way*
overusing macros, and I need to revisit it later. There's basically no
reason for any of the macros added to exist.
There's a few new lints which we had to account for. One is checking for
`assert!(x == y)`. In the case of integer deserialization, I changed the
condition because I actually don't want the error message that
`assert_eq!` would give.
The other new lint is for functions which are pass by value, but only
call methods that take a reference. This was pretty much only false
positives for us. In the case of `diesel_codegen`, that lint triggered
for every `#[proc_macro_derive]` function, where we don't even control
the signature, so I've disabled it crate-wide.
If we want to provide examples for backends other than PG, we'll need to
break this out further into subdirectories. I've also tried to make the
`bin/diesel` script work regardless of subdirectory so there's less
relative path nonsense.
This is the first piece of #196, and somewhat lays the groundwork for
how the rest will be implemented. Getting the examples to compile and
pass was actually quite easy. The hard part was figuring out how to get
the nested cases to fail to compile.
Rather than completely upend our `InsertStatement` structure, I've
instead opted to add a marker trait which we implement in
`#[derive(Insertable)]`. It's a bit of a kludge, but it gets the job
done.
`travis-cargo doc-upload` assumes that the `Cargo.toml` in the cwd is
the manifest for the package being documented, and it also assumes that
the docs are present in `target/doc`. There isn't really any way to make
both of those things true if we're using a workspace, so let's just move
the folder there after we document everything.
Macros 1.1 is now on 1.15 beta. We will not be releasing a new version
until after that beta has launched. Dropping the syntex support from our
own code base makes life easier for development.
This removes the dead code that was laying around as the result of the
now defunct pre-macros 1.1 implementation of codegen. I've also unpinned
the nightly version, as we should no longer break due to changes in
libsyntax. Finally, I've made sure the newly added crates are run as
part of the test suite.
The removal of `.cargo/config` and the addition of `[replace]` all over
the place is to work around
fc0e64262a.
I'm not sure what our long term plan is yet, as juggling that doesn't
sound fun to me.
This was a bit tougher to pull out since the code responsible for
loading the schema information was pretty tightly coupled to libsyntax.
I've attempted to return as much relevant information as possible for
multiple AST frontends in an agnostic way.
This should fix the failures on master as well.
This is required as part of the Macros 1.1 port. I have pinned travis to
a specific nightly, but will unpin it once the port is complete as we
should never break from a nightly again.
Close#426.
I've seen a lot of people making the mistake of trying to put things
like `diesel::types::Timestamp` in their structs. This attempts to
better document the role of the `types` module, and documents any
`ToSql` and `FromSql` impls that are provided. I've un-inlined the pg
types module, as stating "this is a postgres specific type" in the
documentation over and over again didn't feel right. I've also made sure
that the UUID feature is turned on when generating docs.
Having the same crate for both has caused a ton of problems with
linking. I had hoped to just use cargo features for this, but it wasn't
working out that way.
`diesel_codegen` now only targets nightly. `diesel_codegen_syntex`
handles syntex separately (and also contains the common code between the
two crates). Neither crate includes the postgres feature by default.
How to migrate
--------------
If your Cargo.toml previously looked like this:
```rust
[build-dependencies]
diesel_codegen = "0.6.0"
```
it should change to
```rust
[build-dependencies]
diesel_codegen_syntex = { version = "0.7.0", features = ["postgres"] }
```
(You'll need to change the `extern crate` line in `build.rs`)
If your Cargo.toml previously looked like this:
```rust
[dependencies]
diesel_codegen = { version = "0.6.0", default-features = false, features = ["nightly", "postgres"] }
```
it should change to
```rust
[dependencies]
diesel_codegen = { version = "0.7.0", features = ["postgres"] }
```
I've had to split out the cargo features in our test suite, since Cargo
doesn't give me a way to say "turn on the
diesel_codegen_syntex/postgres" feature only if the `with-syntex`
and `postgres` features are on, and I don't want to have to build syntex
every time I run the tests against nightly.
Had to delete the test for the owned value to insert. Message involving
the types is now a note not part of the error. Unsure if this is because
it *actually* changed to a note, or if it's a quirk in compile_tests
0.2.0 (if I test for the note I need to specify *all* notes and the note
on the overflow error is enought o make me not want to do that
We were affected by breaking changes with how struct fields are
represented. Now that I can get the tests compiling, I noticed that I
implemented the `Option` impl for specialization incorrectly.
