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

Crater runs for Rust 1.38.0 #63628

Closed
pietroalbini opened this issue Aug 16, 2019 · 36 comments
Closed

Crater runs for Rust 1.38.0 #63628

pietroalbini opened this issue Aug 16, 2019 · 36 comments
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.

Comments

@pietroalbini
Copy link
Member

cc @rust-lang/release

@pietroalbini
Copy link
Member Author

@craterbot run name=beta-1.38-1 start=1.37.0 end=beta-2019-08-13 mode=build-and-test cap-lints=warn p=10

@craterbot
Copy link
Collaborator

👌 Experiment beta-1.38-1 created and queued.
🔍 You can check out the queue and this experiment's details.

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

@craterbot craterbot added the S-waiting-on-crater Status: Waiting on a crater run to be completed. label Aug 16, 2019
@pietroalbini
Copy link
Member Author

@craterbot run name=beta-1.38-rustdoc-1 start=1.37.0 end=beta-2019-08-13 mode=rustdoc cap-lints=warn p=5

@craterbot
Copy link
Collaborator

👌 Experiment beta-1.38-rustdoc-1 created and queued.
🔍 You can check out the queue and this experiment's details.

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

@craterbot
Copy link
Collaborator

🚧 Experiment beta-1.38-1 is now running on agent aws-1.

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

@Mark-Simulacrum
Copy link
Member

@craterbot run name=beta-1.38-rustdoc-1 p=0

Downgrading rustdoc crater run priority as it usually doesn't catch anything too severe and we have a long Crater queue.

@craterbot
Copy link
Collaborator

🚨 Error: missing start toolchain

🆘 If you have any trouble with Crater please ping @rust-lang/infra!
ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

@Mark-Simulacrum
Copy link
Member

@craterbot name=beta-1.38-rustdoc-1 p=0

@craterbot
Copy link
Collaborator

📝 Configuration of the beta-1.38-rustdoc-1 experiment changed.

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

@craterbot
Copy link
Collaborator

🎉 Experiment beta-1.38-1 is completed!
📊 616 regressed and 26 fixed (70078 total)
📰 Open the full report.

⚠️ If you notice any spurious failure please add them to the blacklist!
ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

@craterbot craterbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-crater Status: Waiting on a crater run to be completed. labels Aug 24, 2019
@petrochenkov
Copy link
Contributor

petrochenkov commented Aug 24, 2019

there are a bunch of macro / derive related regressions errors

Yeah, there were a lot of changes in this area.

Here are all the errors:

// These ones interest me (UPD: All are triaged below).
742 use of unstable library feature 'test': `bench` is a part of custom test frameworks which are unstable
 62 proc-macro derive panicked
 36 failed to resolve: could not find `rustc_serialize` in `{{root}}`
 18 cannot find macro `trace!` in this scope
 12 lifetime name `'s` declared twice in the same scope
 10 cannot find macro `flatdata_intersperse!` in this scope
  5 attributes starting with `rustc` are reserved for use by the `rustc` compiler
  2 lifetime name `'input` declared twice in the same scope
  2 custom attribute panicked
  2 cannot determine resolution for the derive macro `Debug`
  1 proc macro panicked
  1 failed to resolve: use of undeclared type or module `SliceConcatExt`
  1 expected open delimiter
  1 expected one of `!`, `.`, `::`, `;`, `?`, `{`, `}`, or an operator, found `is`
  1 expected module, found unresolved item `crate::mod`

// These ones do not interest me.
191 cannot use `state` because it was mutably borrowed
 94 cannot assign to `self.input.cached_token` because it is borrowed
 38 cannot borrow `v` as immutable because it is also borrowed as mutable
  4 cannot move out of `_` because it is borrowed
  2 cannot borrow `*value` as immutable because it is also borrowed as mutable
  2 cannot borrow `*self` as mutable more than once at a time
  2 `types::log_level_type::LogLevelType` doesn't implement `std::fmt::Debug`
  1 use of moved value: `matches`
  1 type annotations required: cannot resolve `std::boxed::Box<std::iter::Map<std::collections::hash_map::Iter<'_, &T, std::collections::HashSet<&U>>, [closure@src/weighted_rendezvous.rs:490:40: 493:10]>>: std::iter::Iterator`
  1 type annotations required: cannot resolve `std::boxed::Box<std::iter::Map<std::collections::hash_map::Iter<'_, &T, std::collections::HashSet<&U>>, [closure@src/weighted_rendezvous.rs:483:40: 486:10]>>: std::iter::Iterator`
  1 conflicting implementations of trait `std::convert::From<main::LogarithmicKnob>` for type `main::Knob`:
  1 conflicting implementations of trait `std::convert::From<main::LinearKnob>` for type `main::Knob`:
  1 conflicting implementations of trait `main::KnobControl` for type `main::Knob`:
  1 cannot borrow `self.map` as mutable more than once at a time
  1 cannot borrow `*tree` as mutable more than once at a time
  1 cannot borrow `*current` as mutable more than once at a time
  1 assign to part of possibly uninitialized variable: `xgcval`

// Infra
3 linking with `cc` failed: exit code: 1
3 ld returned 1 exit status
1 multiple matching crates for `local_encoding`
1 multiple matching crates for `docmatic`
1 can't find crate for `local_encoding`
1 can't find crate for `docmatic`
1 the lock file /mnt/big/crater/work/ex/beta-1.38-1/sources/1.37.0/gh/xi-frontend/xi-term/Cargo.lock needs to be updated but --locked was passed to prevent this
1 the lock file /mnt/big/crater/work/ex/beta-1.38-1/sources/1.37.0/gh/Prorok64b/web_crawler/Cargo.lock needs to be updated but --locked was passed to prevent this
1 the lock file /mnt/big/crater/work/ex/beta-1.38-1/sources/1.37.0/gh/mneumann/graph-similarity-cmd/Cargo.lock needs to be updated but --locked was passed to prevent this
1 the lock file /mnt/big/crater/work/ex/beta-1.38-1/sources/1.37.0/gh/MalteT/mensa/Cargo.lock needs to be updated but --locked was passed to prevent this
1 the lock file /mnt/big/crater/work/ex/beta-1.38-1/sources/1.37.0/gh/git-series/git-series/Cargo.lock needs to be updated but --locked was passed to prevent this
1 the lock file /mnt/big/crater/work/ex/beta-1.38-1/sources/1.37.0/gh/0X1A/core-utils/Cargo.lock needs to be updated but --locked was passed to prevent this
1 scenario did not finish successfully: \"2\"\nscenarios:   -> reason: job exited with non-zero exit code: 1\nscenarios: not all scenarios terminated successfully\n"`,
1 scenario did not finish successfully: \"1\"\nscenarios:   -> reason: job exited with non-zero exit code: 1\nscenarios: not all scenarios terminated successfully\n"`', tests/tests.rs:420:9
1 process didn't exit successfully: `/opt/crater/target/debug/deps/test_calls-e2efa9867cc7232e` (signal: 4, SIGILL: illegal instruction)
1 process didn't exit successfully: `/opt/crater/target/debug/deps/smalloca-4a140daaf79cea64` (signal: 4, SIGILL: illegal instruction)
1 process didn't exit successfully: `/opt/crater/target/debug/deps/mujs-5e5e5db7b26bab7e` (signal: 4, SIGILL: illegal instruction)
1 process didn't exit successfully: `/opt/crater/target/debug/deps/esr-2b38354cb0dbd2fa` (signal: 11, SIGSEGV: invalid memory reference)
1 process didn't exit successfully: `/opt/crater/target/debug/deps/consistenttime-f55c7a6e800763f5` (signal: 4, SIGILL: illegal instruction)

@petrochenkov
Copy link
Contributor

use of unstable library feature 'test': bench is a part of custom test frameworks which are unstable

This is caused by #62507 and tracked by #63798.

@CAD97
Copy link
Contributor

CAD97 commented Aug 24, 2019

Does crater respect Cargo.lock? I wonder what percentage of the #[bench] attributes come from e.g. route-recognizer and would go away with a cargo update.

@petrochenkov
Copy link
Contributor

failed to resolve: could not find rustc_serialize in {{root}}

Caused by #63449.
Tests in rustc-serialize and its fork rustc-serialize2 are broken, no other crates are affected.
(Can be fixed with extern crate self as rustc_serivalize;.)
Probably no action required.

@petrochenkov
Copy link
Contributor

petrochenkov commented Aug 24, 2019

lifetime name 's declared twice in the same scope

lifetime name 'input declared twice in the same scope

./reg/cff/0.5.0/beta-2019-08-13.txt:[INFO] [stderr] error[E0263]: lifetime name `'s` declared twice in the same scope
./reg/sfnt/0.12.0/beta-2019-08-13.txt:[INFO] [stderr] error[E0263]: lifetime name `'s` declared twice in the same scope
./reg/tarrasque/0.10.0/beta-2019-08-13.txt:[INFO] [stderr] error[E0263]: lifetime name `'s` declared twice in the same scope

./reg/reformation/0.4.1/beta-2019-08-13.txt:[INFO] [stdout] error[E0263]: lifetime name `'input` declared twice in the same scope

This may be something caused by derive hygienization (#63462 or some of the earlier PRs) and/or this PR - #63501.
cc @matthewjasper @nikomatsakis

@petrochenkov
Copy link
Contributor

attributes starting with rustc are reserved for use by the rustc compiler

./reg/select-rustc/0.1.2/beta-2019-08-13.txt:[INFO] [stdout] error[E0658]: attributes starting with `rustc` are reserved for use by the `rustc` compiler

Expected breakage from #62133, attributes of the form rustc::anything are now reserved for rustc.

@petrochenkov
Copy link
Contributor

cannot find macro trace! in this scope

cannot find macro flatdata_intersperse! in this scope

./reg/eztrace/0.1.0/beta-2019-08-13.txt:[INFO] [stderr] error: cannot find macro `trace!` in this scope

./reg/flatdata/0.3.0/beta-2019-08-13.txt:[INFO] [stderr] error: cannot find macro `flatdata_intersperse!` in this scope

Regression from #63114, fixed in #63717.
(The fix still needs a backport to beta.)

@petrochenkov
Copy link
Contributor

expected open delimiter

./reg/dtolnay/0.0.2/beta-2019-08-13.txt:[INFO] [stderr] error: expected open delimiter

Expected breakage of an unstable feature (my_macro! name { ... } no longer parses), caused by #62258.

@petrochenkov
Copy link
Contributor

expected one of !, ., ::, ;, ?, {, }, or an operator, found is

./reg/google-games1/1.0.10+20190627/beta-2019-08-13.txt:[INFO] [stdout] error: expected one of `!`, `.`, `::`, `;`, `?`, `{`, `}`, or an operator, found `is`

Minimized reproduction, run with rustdoc --test (all the whitespace is important!):

/// #
///
///     ident ident
fn f() {}

Apparently something makes this comment look like code to rustdoc, so it tries to doctest it.

Actually, stable rustdoc also gives an error for this, from what I tried locally, not sure why it passed on crater.
cc @rust-lang/rustdoc

@matthewjasper
Copy link
Contributor

lifetime name 's declared twice in the same scope

lifetime name 'input declared twice in the same scope

This is due to #63083. E0263 now compares identifiers with modern hygiene rather than directly.

./reg/cff/0.5.0/beta-2019-08-13.txt:[INFO] [stderr] error[E0263]: lifetime name `'s` declared twice in the same scope
./reg/sfnt/0.12.0/beta-2019-08-13.txt:[INFO] [stderr] error[E0263]: lifetime name `'s` declared twice in the same scope
./reg/tarrasque/0.10.0/beta-2019-08-13.txt:[INFO] [stderr] error[E0263]: lifetime name `'s` declared twice in the same scope

Relevant code: https://docs.rs/tarrasque-macro/0.10.0/src/tarrasque_macro/lib.rs.html#193. 's is being added to the parameters even when it's already there.
cc @KyleMayes

./reg/reformation/0.4.1/beta-2019-08-13.txt:[INFO] [stdout] error[E0263]: lifetime name `'input` declared twice in the same scope

Appears to be fixed in the recently published 0.5.0

@shepmaster
Copy link
Member

Apparently something makes this comment look like code to rustdoc, so it tries to doctest it.

The comment (// ) is followed by 4 spaces ( ), Markdown syntax for a code block.

See also:

@petrochenkov
Copy link
Contributor

expected module, found unresolved item crate::mod

./gh/xi-frontend/xi-term/beta-2019-08-13.txt:[INFO] [stderr] error[E0577]: expected module, found unresolved item `crate::mod`

This is the most hilarious case so far.
Apparently due to some recovery going wrong paths like {crate,self,super}::r#keyword silently resolve to Res::Err without reporting any error (I've made an issue for this - #63882).

Code in xrl-0.0.7 looked like this

pub(in crate::r#mod) fn new() { ... }

and it broke when visibility resolution switched to a different algorithm ("early resolution") in #63400, which doesn't have this bug.
I'd expect this issue to be discoverable by some kind of fuzzing, but I'd never expect it to be encountered by real code!

So, the regression is a bugfix and this bug needs to be fixed in other contexts as well, #63882 is the tracking issue for that.

@petrochenkov
Copy link
Contributor

failed to resolve: use of undeclared type or module SliceConcatExt

./gh/echupriyanov/tls-ws/beta-2019-08-13.txt:[INFO] [stderr] error[E0433]: failed to resolve: use of undeclared type or module `SliceConcatExt`

SliceConcatExt was an unstable standard library trait removed in #62403.

@petrochenkov
Copy link
Contributor

petrochenkov commented Aug 25, 2019

cannot determine resolution for the derive macro Debug

./reg/ruroonga_command/0.3.4/beta-2019-08-13.txt:[INFO] [stderr] error: cannot determine resolution for the derive macro `Debug`

Minimized:

use Enum::Debug;

#[derive(Debug)] // Add some more derives if the error does not reproduce
enum Enum {
    Debug
}

This is a regression from #63248, and #63867 works in the same direction but hasn't landed yet.

Basically, the import is blocked until the derive is expanded and the derive is blocked until the import is resolved, so we have a deadlock.

This worked previously, because we did some things in less principled way (textual comparisons instead of resolution), which allowed us to produce the enum earlier, before resolving the Debug, but now we need to resolve it before producing the Enum.

This is fixable in principle, by making the expansion infra more fine-grained (introducing some new "resolved, but not yet ready for expansion" states), but I'm afraid that's not something that could be backported to beta.
So, I'd say wontfix. Unfortunate, but seems acceptable given the number of affected crates (one regression found).

@pietroalbini
Copy link
Member Author

@petrochenkov all this triage look great, but it's not easily actionable if it's all done in this issue. Could you move each regression to its own issue, and maybe add checkboxes in your list here to track the progress?

@petrochenkov
Copy link
Contributor

petrochenkov commented Aug 25, 2019

Ok, I'll make separate issues once I've looked at the remaining regressions.

UPD: Done.

@petrochenkov
Copy link
Contributor

petrochenkov commented Aug 25, 2019

proc macro panicked

[INFO] [stderr]    Compiling custom-slice-macros v0.1.1 (/opt/crater/workdir)
[INFO] [stderr] error: proc macro panicked
[INFO] [stderr]    --> tests/derives.rs:48:13
[INFO] [stderr]     |
[INFO] [stderr] 48  | /             custom_slice_macros::define_slice_types_pair! {
[INFO] [stderr] 49  | |                 #[custom_slice(owned)]
[INFO] [stderr] 50  | |                 $(#[$meta_owned])*
[INFO] [stderr] 51  | |                 struct Owned($owned_inner);
[INFO] [stderr] ...   |
[INFO] [stderr] 59  | |                 fn validate(_: &$slice_inner) -> Result<(), $ty_error> $body
[INFO] [stderr] 60  | |             }
[INFO] [stderr]     | |_____________^
[INFO] [stderr] ...
[INFO] [stderr] 227 | /     gen_test! {
[INFO] [stderr] 228 | |         name: try_from_inner,
[INFO] [stderr] 229 | |         #[custom_slice(derive(TryFromInner))]
[INFO] [stderr] 230 | |         #[custom_slice(error(r#type = "()"))]
[INFO] [stderr] ...   |
[INFO] [stderr] 236 | |         validator: () { Ok(()) },
[INFO] [stderr] 237 | |     }
[INFO] [stderr]     | |_____- in this macro invocation
[INFO] [stderr]     |
[INFO] [stderr]     = help: message: `#[custom_slice(error(type = "..."))]` should be specified

This is a regression from these series of pretty-printing improvements - #62393, #62574, #62667.

Tokens are printed more precisely now, so #[custom_slice(error(r#type = "()"))] is now printed as is, while previously it lost the "rawness" qualifier from type and was printed like this - #[custom_slice(error(type = "()"))].
(Pretty-printing matters because proc macros often have to work with pretty-printed version of their input due to #43081.)

Procedural macro define_slice_types_pair however doesn't recognize r#type as type and complains.

@petrochenkov
Copy link
Contributor

petrochenkov commented Aug 25, 2019

custom attribute panicked

[INFO] [stderr]    Compiling display-as v0.4.6 (/opt/crater/workdir)
[INFO] [stderr] error: custom attribute panicked
[INFO] [stderr]    --> tests/format_as.rs:104:5
[INFO] [stderr]     |
[INFO] [stderr] 104 |     #[with_template("Foo " self.0)]
[INFO] [stderr]     |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[INFO] [stderr]     |
[INFO] [stderr]     = help: message: with_template must be applied to an impl that ends in '{}', not { }

One more victim to the pretty-printing changes (#62667), whitespace-related in this case.

Here's what the macro does:

    if last.to_string() != "{  }" {
        /* report error */
    }

Pretty unreliable check, isn't it?

@sgrif
Copy link
Contributor

sgrif commented Aug 25, 2019 via email

@petrochenkov
Copy link
Contributor

proc-macro derive panicked

[INFO] [stderr] error: proc-macro derive panicked
[INFO] [stderr]   --> src/lib.rs:11:1
[INFO] [stderr]    |
[INFO] [stderr] 11 | / proc_macro_item_decl! {
[INFO] [stderr] 12 | |     /// Generates a default blanket impl for a generic trait that gets passed into
[INFO] [stderr] 13 | |     /// `autoimpl!`, with the same type parameters and type bounds as its trait.
[INFO] [stderr] 14 | |     ///
[INFO] [stderr] ...  |
[INFO] [stderr] 44 | |     autoimpl! => generate_auto_impl_impl
[INFO] [stderr] 45 | | }
[INFO] [stderr]    | |_^
[INFO] [stderr]    |
[INFO] [stderr]    = help: message: assertion failed: `(left == right)`
[INFO] [stderr]              left: `Some("#[allow(unused,")`,
[INFO] [stderr]             right: `Some("#[allow(unused")`

All of the 62 regressions are due to old versions of proc-macro-hack having an assert expecting #[allow(unused, instead of #[allow(unused ,.
So this is again a consequence of whitespace changes in pretty-printing (#62667).

I think we should be able to fix this by special casing the comma token during token stream pretty-printing and not printing the space before it.

@craterbot
Copy link
Collaborator

🚧 Experiment beta-1.38-rustdoc-1 is now running on agent aws-1.

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

@craterbot
Copy link
Collaborator

🎉 Experiment beta-1.38-rustdoc-1 is completed!
📊 757 regressed and 2 fixed (70078 total)
📰 Open the full report.

⚠️ If you notice any spurious failure please add them to the blacklist!
ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

@petrochenkov
Copy link
Contributor

petrochenkov commented Oct 18, 2019

Did anyone triage the regressions not related to the frontend?
"cannot use state because it was mutably borrowed" and below.
I didn't look at them.

1.38 was released a few weeks ago so it's too late to do it now, but if they weren't triaged that means some kind of a process break.

@Mark-Simulacrum
Copy link
Member

I suspect no -- I thought all regressions were triaged (and issues opened, etc.)

@petrochenkov
Copy link
Contributor

Made an issue - #65577.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.
Projects
None yet
Development

No branches or pull requests

9 participants