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

linux1b bot isn't working #7647

Closed
Aatch opened this issue Jul 8, 2013 · 1 comment
Closed

linux1b bot isn't working #7647

Aatch opened this issue Jul 8, 2013 · 1 comment

Comments

@Aatch
Copy link
Contributor

Aatch commented Jul 8, 2013

The linux1b bot is the only bot servicing snapshots and it just can't do it. It takes hours to even fail, which suggests that isn't hanging, but instead is thrashing and occassionally coughs up a few bytes which keeps the buildbot master happy.

I cancelled it building a snapshot after 10 hours, and the most recent failure was it killed after 6.

@graydon @brson this is blocking a new snapshot

@huonw
Copy link
Member

huonw commented Aug 19, 2013

Triage visit: appears to be working fine now (the most recent build took 2.5hrs and was successful).

@huonw huonw closed this as completed Aug 19, 2013
flip1995 pushed a commit to flip1995/rust that referenced this issue Oct 6, 2022
…ems, r=llogiq

Fix and improve `match_type_on_diagnostic_item`

This extracts the fix for the lint out of rust-lang#7647. There's still a couple of other functions to check, but at least this will get lint working again.

The two added util functions (`is_diagnostic_item` and `is_lang_item`) are needed to handle `DefId` for unit and tuple struct/variant constructors. The `rustc_diagnostic_item` and `lang` attributes are attached to the struct/variant `DefId`, but most of the time they are used through their constructors which have a different `DefId`. The two utility functions will check if the `DefId` is for a constructor and switch to the associated struct/variant `DefId`.

There does seem to be a bug on rustc's side where constructor `DefId`s from external crates seem to be returning `DefKind::Variant` instead of `DefKind::Ctor()`. There's a workaround put in right.

changelog: None
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants