Skip to content
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

"expected struct `std::boxed::Box`, found struct `std::string::String`", scan-rules 0.2.0, Rust 1.17 nightly #39826

Closed
brson opened this Issue Feb 14, 2017 · 4 comments

Comments

Projects
None yet
4 participants
@brson
Copy link
Contributor

brson commented Feb 14, 2017

brian@ip-10-145-43-250:~/dev/rust-scan-rules⟫ git remote -v
origin  https://github.com/DanielKeep/rust-scan-rules (fetch)
origin  https://github.com/DanielKeep/rust-scan-rules (push)
brian@ip-10-145-43-250:~/dev/rust-scan-rules⟫ git log -1
commit 151b4d822c33dcb8a04d9fa55d1084c948e5b76d
Author: Daniel Keep <daniel.keep@gmail.com>
Date:   Mon Nov 7 16:27:19 2016 +1100

    chore: updated docs for release.
brian@ip-10-145-43-250:/mnt2/dev⟫ rustc +stable -Vv
rustc 1.15.1 (021bd294c 2017-02-08)
binary: rustc
commit-hash: 021bd294c039bd54aa5c4aa85bcdffb0d24bc892
commit-date: 2017-02-08
host: x86_64-unknown-linux-gnu
release: 1.15.1
LLVM version: 3.9
101 brian@ip-10-145-43-250:~/dev/rust-scan-rules⟫ cargo +nightly test
   Compiling bitflags v0.4.0
   Compiling semver v0.1.20
   Compiling unicode-segmentation v0.1.3
   Compiling lazy_static v0.1.16
   Compiling itertools v0.4.19
warning[E0122]: trait bounds are not (yet) enforced in type definitions
   --> /home/brian/.cargo/registry/src/github.com-1ecc6299db9ec823/itertools-0.4.19/src/lib.rs:123:1
    |
123 | pub type MapFn<I, B> where I: Iterator = iter::Map<I, fn(I::Item) -> B>;
    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

   Compiling rustc_version v0.1.7
   Compiling strcursor v0.2.3
   Compiling scan-rules v0.2.0 (file:///mnt2/dev/rust-scan-rules)
error[E0308]: mismatched types
   --> /home/brian/.cargo/registry/src/github.com-1ecc6299db9ec823/strcursor-0.2.3/src/grapheme.rs:525:15
    |
525 |         GcBuf(s)
    |               ^ expected struct `std::boxed::Box`, found struct `std::string::String`
    |
    = note: expected type `std::boxed::Box<str>`
               found type `std::string::String`
    = help: here are some functions which might fulfill your needs:
            - .into_boxed_str()

error: aborting due to previous error

error: Could not compile `strcursor`.

To learn more, run the command again with --verbose.

Not on 1.15. Different from 1.16 #39825

cc @DanielKeep

@arielb1

This comment has been minimized.

Copy link
Contributor

arielb1 commented Feb 16, 2017

libs team - does this look like XIB (expected inference breakage) to you?

@brson

This comment has been minimized.

Copy link
Contributor Author

brson commented Mar 1, 2017

Also in strcursor-0.2.3

@nikomatsakis

This comment has been minimized.

Copy link
Contributor

nikomatsakis commented Mar 1, 2017

cc @rust-lang/libs -- it sure smells like expected inference breakage of some kind or another (as @arielb1 noted, but didn't cc the alias).

@alexcrichton

This comment has been minimized.

Copy link
Member

alexcrichton commented Mar 1, 2017

I believe the crate in the title, scan-rules, is a red herring. The original log (in the OP) and @brson's most recent comment lead me to believe that this is only a problem with the strcursor crate.

In that crate the type in question is conditionally compiled based off a #[cfg] value. If the cfg is set, the crate will not compile (as one would expect). On 1.16.0 the build script is not picked up (there's no build = "build.rs") but on 1.17.0 we're picking it up by default (this changed in Cargo). That means that on Rust 1.16.0 we're not running a build script, the cfg isn't set, and the crate compiles just fine. On Rust 1.17.0 the build script is auto-detected, the cfg is set, and the crate fails to compile.

Looking at the history of the crate it looks like build = "build.rs" has never been present, so I presume that this commit accidentally forgot to add it, and ever since the crate has accidentally been compiling.

@DanielKeep does all that sound right to you?

In any case I don't believe this is a regression, so I'm going to close in the meantime. @DanielKeep if you need any help updating though please let me know!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.