-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
#[rustc_error] survey #55532
#[rustc_error] survey #55532
Conversation
(rust_highfive has picked a reviewer for you, use r? to override) |
@bors r+ |
📌 Commit 51fd805dfc8fc84ccefffb2a9511530116845668 has been approved by |
⌛ Testing commit 51fd805dfc8fc84ccefffb2a9511530116845668 with merge 56d741945fbc18d539fe5664c3c18e68db41b983... |
💔 Test failed - status-travis |
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
51fd805
to
b1d39bf
Compare
@bors r=nikomatsakis |
📌 Commit b1d39bf26143c15a91811d1978c521621fc39441 has been approved by |
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
⌛ Testing commit b1d39bf26143c15a91811d1978c521621fc39441 with merge 3d39e57933b85fd823de5f16f8c9095e1b6f2949... |
💔 Test failed - status-travis |
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
The bors queue has a spurious failure (30 min timeout which is likely related to 9696), but the CI PR reported in #55532 (comment) looks legit, so I'm not going to retry. |
That is very goofy. I do not see that test result locally (when testing stage1). Is there any chance that our diagnostic here is behaving differently on different platforms...? (or that the behavior somehow differs between stage1 and stage2 here...?)
|
(isn't it also weird that the travis result says this:
Why is that occurring twice? |
Oh, the raw log has it only once. So that's something wrong with some other piece of post-processing, I guess |
b1d39bf
to
505db16
Compare
This test specifically notes that it does not want to invoke the linker, due to the way it (IMO weakly) exercises the `#[link=...]` attribute. In any case, removing the the `#[rustc_error]` here uncovered an "invalid windows subsystem" error that was previously not included in the transcript of diagnostic output. So that's a step forward, (right?).
I also added `// skip-codegen` to each one, to address potential concerns that this change would otherwise slow down our test suite spending time generating code for files that are really just meant to be checks of compiler diagnostics. (However, I will say: My preference is to not use `// skip-codegen` if one can avoid it. We can use all the testing of how we drive LLVM that we can get...) (Updated post rebase.)
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
okay ... at this point I assume this must be some weird artifact of my own environment, maybe some customization in my |
(ah it might be due to an |
Yes, okay, the presence/absence of |
I usually add |
…rom `rustc -O`. (The fact that output differs under `opt-level=0` is an instance of rust-lang#55757.)
505db16
to
58c7a78
Compare
@bors r=nikomatsakis |
📌 Commit f4da71e has been approved by |
☀️ Test successful - status-appveyor, status-travis |
Fix #55505