I’m working on systemd-cron-next project and I depend on a few unstable features, so I had to use nightly Rust compiler.
I haven’t updated my rust compiler for a while and everything worked just fine, until recently I turned on Travis CI for the project, and it failed to compile with latest nightly.
I updated my compiler and try to cargo build my project, and it failed:
I use build.rs script with rumblebars crate to generate some files from templates.
I’m not sure since what nightly version the code was broken, but rustc 1.3.0-nightly (69ca01256 2015-07-23) is already broken, while rustc 1.3.0-nightly (7ea2674c7 2015-07-13) works perfectly fine, so whatever regression happened in rust nightly, it was between 7/13 and 7/23.
Auto merge of #27026 - nagisa:overflowing-unsigned, r=pnkfelix
This commit fixes the negate_unsigned feature gate to appropriately
account for inferred variables.
This is technically a [breaking-change], but I’d consider it a bug fix.
cc @brson for your relnotes.
Fixes https://github.com/rust-lang/rust/issues/24676
Fixes #26840
Fixes https://github.com/rust-lang/rust/issues/25206
Auto merge of #27045 - nikomatsakis:better-object-defaults-error, r=pnkfelix
Transition to the new object lifetime defaults, replacing the old defaults completely.
r? @pnkfelix
This is a [breaking-change] as specified by [RFC 1156][1156] (though all cases that would break should have been receiving warnings
starting in Rust 1.2). Types like &'a Box<Trait> (or &'a Rc<Trait>, etc) will change from being interpreted as &'a Box<Trait+'a> to &'a Box<Trait+'static>. To restore the old
behavior, write the +'a explicitly. For example, the function:
```rust
trait Trait { }
fn foo(x: &Box<Trait>) { ... }
```
would be rewritten as:
```rust
trait Trait { }
fn foo(x: &'a Box<Trait+'a>) { ... }
```
if one wanted to preserve the current typing.
[1156]: https://github.com/rust-lang/rfcs/blob/master/text/1156-adjust-default-object-bounds.md
Fix negate_unsigned feature gate check
This commit fixes the negate_unsigned feature gate to appropriately
account for infered variables.
This is technically a [breaking-change].
And these changes don't look relevant to my problem for me.
Maybe you need to ask the rumblebars maintainer for specifics?
I see you are using "*" versions for dependencies, so you’ll always get the latest versions of crates – even if they have been updated incompatibly. I’d suggest always using versioned dependencies, that way you don’t at least opt in to automatic breakage.
That said, discuss with the rumblebars maintainer, do they intend to support rust nightly? Is there a version of it that does (and which cargo feature flags would it need)?