Closed pietroalbini closed 4 years ago
@craterbot run name=beta-1.40-1 start=1.39.0 end=beta-2019-11-06 mode=build-and-test cap-lints=warn p=10
:ok_hand: Experiment beta-1.40-1
created and queued.
:mag: You can check out the queue and this experiment's details.
:information_source: Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more
:construction: Experiment beta-1.40-1
is now running
:information_source: Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more
@craterbot run name=beta-1.40-rustdoc-1 start=1.39.0 end=beta-2019-11-06 mode=rustdoc cap-lints=warn p=5
:ok_hand: Experiment beta-1.40-rustdoc-1
created and queued.
:mag: You can check out the queue and this experiment's details.
:information_source: Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more
:construction: Experiment beta-1.40-rustdoc-1
is now running
:information_source: Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more
:tada: Experiment beta-1.40-1
is completed!
:bar_chart: 1072 regressed and 38 fixed (77633 total)
:newspaper: Open the full report.
:warning: If you notice any spurious failure please add them to the blacklist! :information_source: Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more
root: axgeom - 2 (0 gh, 2 crates.io) detected crates which regressed due to this; cc @tiby312
root: capnp - 4 (1 gh, 3 crates.io) detected crates which regressed due to this; cc @dwrensha
root: epub - 4 (2 gh, 2 crates.io) detected crates which regressed due to this; cc @danigm
root: galvanize - 2 (0 gh, 2 crates.io) detected crates which regressed due to this; cc @estebank
root: gfx-hal - 4 (2 gh, 2 crates.io) detected crates which regressed due to this; cc @kvark
root: gltf - 10 (6 gh, 4 crates.io) detected crates which regressed due to this; cc @alteous
~root: gstreamer - 3 (3 gh, 0 crates.io) detected crates which regressed due to this; cc @arturoc, @sdroege, @tp-m~
root: hpack_codec - 3 (1 gh, 2 crates.io) detected crates which regressed due to this; cc @sile
root: liner - 6 (5 gh, 1 crates.io) detected crates which regressed due to this; cc @MovingtoMars
root: liquid-value - 6 (4 gh, 2 crates.io) detected crates which regressed due to this; cc @epage
root: nalgebra - 189 (178 gh, 11 crates.io) detected crates which regressed due to this; cc @sebcrozet, @aepsil0n
root: nero - 2 (1 gh, 1 crates.io) detected crates which regressed due to this; cc @staticfox
root: rusttype - 228 (227 gh, 1 crates.io) detected crates which regressed due to this; cc @dylanede, @jackpot51, @alexheretic
root: syntex_syntax - 4 (2 gh, 2 crates.io) detected crates which regressed due to this; cc @erickt, @Manishearth, @pcwalton
root: three - 9 (9 gh, 0 crates.io) detected crates which regressed due to this; cc @kvark
root: gstreamer - 3 (3 gh, 0 crates.io) detected crates which regressed due to this; cc @arturoc, @sdroege, @tp-m
This is for an old version of the gstreamer
crate and already fixed since many months in the newer versions. The crates using the old version will have to update.
root: thrussh - 3 (2 gh, 1 crates.io) detected crates which regressed due to this; cc @P-E-Meunier
~root: url - 506 (501 gh, 5 crates.io) detected crates which regressed due to this; cc @SimonSapin, @Hoverbear, @seanmonstar~
root: vek - 4 (4 gh, 0 crates.io) detected crates which regressed due to this; cc @yoanlcq
root: version-compare - 8 (6 gh, 2 crates.io) detected crates which regressed due to this; cc @timvisee
root: unknown causes - 28 (16 gh, 12 crates.io) detected crates which regressed due to thisno owner?
root: liquid-value - 6 (4 gh, 2 crates.io) detected crates which regressed due to this;
These are using liquid 0.18. 0.19 has this issue fixed.
root: url - 506 (501 gh, 5 crates.io) detected crates which regressed due to this
TL;DR: NLL-only error, upstream already has a fix, nothing to do here.
I looked at the “end” log for a dozen of those at semi-random. They all have:
`[INFO] crate git repo https://github.com/[…] has a lockfile, it will not be regenerated
And they are all for the same borrowck error that was fixed in https://github.com/servo/rust-url/pull/454 which was published in https://crates.io/crates/url/1.7.1 last year.
Running cargo update -p url
in those project should be enough for them to pick up the fix.
At first I was surprised that Crater found this only for 1.40 rather than 1.39, but this matches https://blog.rust-lang.org/2019/11/07/Rust-1.39.0.html#borrow-check-migration-warnings-are-hard-errors-in-rust-2018
With Rust 1.39.0, these warnings are now errors in Rust 2018. In the next release, Rust 1.40.0, this will also apply to Rust 2015,
* root: sdl2-0.32.2: [start](https://crater-reports.s3.amazonaws.com/beta-1.40-1/1.39.0/reg/sdl2-0.32.2/log.txt) v. [end](https://crater-reports.s3.amazonaws.com/beta-1.40-1/beta-2019-11-06/reg/sdl2-0.32.2/log.txt); cc @ bvssvni, @ AngryLawyer, @Cobrand
This is a probably a false positive, this error is caused by the fact that test runs in sdl2 can't be run in parallel. We have the RUST_TEST_THREADS=1
env variable for our travis tests, but obviously it isn't picked properly by crater, and I don't know of a way to explicitly mention this in Cargo.toml, let alone crater itself.
rotor
and rotor-tools
are stale and should not be used any more (I might need to yank them?). But they trigger internal compiller error (ICE) which should be important to fix nevertheless.
Please don't triage crater runs on this issue, otherwise we're likely to forget to follow up. File new issues (possibly closed immediately) instead.
Please don't triage crater runs on this issue,
If replying to a comment that @-mention people is not the expected response from those people, instructions should be at the top of the template for those comments.
File new issues (possibly closed immediately) instead.
This sounds like busywork, when there’s nothing more to do.
If you really want one issue for each root regression, consider filing them as soon as the regressions are found and @-mentioning crate maintainers there instead of in a thread where they’re not expected to respond.
If replying to a comment that @-mention people is not the expected response from those people, instructions should be at the top of the template for those comments.
Hm, this seems to be coming from a point of confusion -- this issue is not intended to be anything more than a place to run craterbot from. The template for that comment is from a ad-hoc tool intended for mostly internal use, not for direct posting in most cases. I agree that the UX here could be better, but to be honest, it's unexpected that someone just goes in to triage a crater run without asking for some guidance from release team or other wise first, particularly in a way that'll ping lots of folks.
With regards to closing issues immediately, I agree it feels like busywork and sometimes it's fine to say "known regression, intended" when triaging and not open an issue, but unless it's very clear, an issue gives the opportunity for it to be visible to folks who are watching new issues come in and potentially for discussion/concerns to be raised, as well as a spot to ping crate authors in a low-noise way as further comments on that issue are not expected, unless there's (unexpected) discussion.
If you really want one issue for each root regression, consider filing them as soon as the regressions are found and @-mentioning crate maintainers there instead of in a thread where they’re not expected to respond.
This is kind of true -- ideally, the root regressions are triaged individually and an issue is filed that identifies or groups by the root cause (not crate, but e.g., PR landing in this repository or feature, etc.).
That's what the normal process for crater triage is.
it's unexpected that someone just goes in to triage a crater run
@-mentioning someone in a GitHub issue signals an expectation of them to respond or take action in some way.
If no response at all is expected of them, crate maintainers should not be @-mentioned like in https://github.com/rust-lang/rust/issues/66244#issuecomment-552903470
Yes, my comment was primarily directed towards the original comments -- i.e., https://github.com/rust-lang/rust/issues/66244#issuecomment-552895213 -- rather than your response, sorry for not making that clear.
Oh, the formatting of that comment looks so systematic that I assumed it’s (semi-)automated and part of the triage process.
Oh, the formatting of that comment looks so systematic that I assumed it’s (semi-)automated and part of the triage process.
It is -- https://github.com/Mark-Simulacrum/crater-generate-report/ -- but not intended to be used like this, more so to create a doc locally to work through.
:tada: Experiment beta-1.40-rustdoc-1
is completed!
:bar_chart: 1193 regressed and 0 fixed (77633 total)
:newspaper: Open the full report.
:warning: If you notice any spurious failure please add them to the blacklist! :information_source: Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more
Hello, I saw I was mentioned in this issue - as the maintainer of vek
, is there anything I am supposed to do ? I am not quite able to figure out what is going on. :x
Thanks in advance!
There is not currently any expected action for crate authors, no.
- root: smoltcp-0.5.0
This one is fixed in smoltcp master, but the underlying soundness issue was irritating enough that I wrote a pre-RFC to fix it properly. If there's any interest in advancing that I might incorporate the feedback and try again.
Filed issues from crater triage:
https://github.com/rust-lang/rust/issues/66517 (NLL) https://github.com/rust-lang/rust/issues/66516 (match arms incompatible types) https://github.com/rust-lang/rust/issues/66518 (matches macro conflicts)
cc @rust-lang/release