Skip to content

'rustc' failed at 'called Result::unwrap() on an Err value' #13517

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

#

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Jump to bottom
Closed
blastrock opened this issue Apr 14, 2014 · 1 comment
Closed

'rustc' failed at 'called Result::unwrap() on an Err value' #13517

blastrock opened this issue Apr 14, 2014 · 1 comment
Labels
E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion. I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️

Comments

@blastrock
Copy link

When you run

rustc a.rs --dep-info b/c/d

with "b/c/d" a non existent path, rustc fails with:

error: internal compiler error: unexpected failure
note: the compiler hit an unexpected failure path. this is a bug.
note: we would appreciate a bug report: http://static.rust-lang.org/doc/master/complement-bugreport.html
note: run with `RUST_BACKTRACE=1` for a backtrace
task 'rustc' failed at 'called `Result::unwrap()` on an `Err` value', /home/blastrock/packages/rust/src/libstd/result.rs:187
stack backtrace:
   1:     0x7f26140d9a20 - rt::backtrace::imp::write::h987c266f24b5dc06gZb::v0.10
   2:     0x7f261403ad50 - rt::unwind::begin_unwind_inner::hb9f03d7eac5ad766Jzb::v0.10
   3:     0x7f2614c98fb0 - rt::unwind::begin_unwind::h4d23f723c663afb4nfr::v0.10
   4:     0x7f26154946f0 - driver::driver::compile_input::h114b1222f6ba70aesWf::v0.10
   5:     0x7f26154b8be0 - run_compiler::hc8f4096777353458Yzn::v0.10
   6:     0x7f26154d0320 - main_args::closure.92072
   7:     0x7f26154cec50 - monitor::closure.91957
   8:     0x7f26154ca630 - task::TaskBuilder::try::closure.91732
   9:     0x7f261477cf80 - task::spawn_opts::closure.7828
  10:     0x7f26140d4b00 - rt::task::Task::run::closure.41627
  11:     0x7f26140e0470 - rust_try
  12:     0x7f26140d4a50 - rt::task::Task::run::hf5faab7a4b27dcc1fs9::v0.10
  13:     0x7f261477cd50 - task::spawn_opts::closure.7801
  14:     0x7f26140d8570 - rt::thread::thread_start::hed02916383a2b92bW69::v0.10
  15:     0x7f26119a6f40 - start_thread
  16:     0x7f2613d06179 - clone
  17:                0x0 - <unknown>
@flaper87
Copy link
Contributor

cc #12865 not exactly the same bug but still related. I'm willing to mentor on this fix.

@flaper87 flaper87 mentioned this issue Apr 14, 2014
Closed
@apaprocki apaprocki mentioned this issue Apr 19, 2014
Closed
notriddle pushed a commit to notriddle/rust that referenced this issue Nov 10, 2022
@bors
Auto merge of rust-lang#13517 - feniljain:fix_completions, r=Veykril
12ced8f 
fix: make custom expr prefix completions to understand refs

Possible fix of rust-lang#7929

While reviewing the postfix completion code I saw that while calling `add_custom_postfix_completions` we were doing it under the part where reference was not taken into consideration, but as we are only adding postfix completions with `Expr` scope ( [source](https://github.com/rust-lang/rust-analyzer/blob/ba28e19b7838e3ad4223ae82d074dc3950ef1548/crates/ide-completion/src/completions/postfix.rs#L272) )

I shifted the `add_custom_postfix_completions` call to part where references are considered

I am not sure if this is the correct fix or I am understanding the problem exactly but this small move seemed to have fixed the issue :)
arcnmx pushed a commit to arcnmx/rust that referenced this issue Dec 17, 2022
@bors
Auto merge of rust-lang#13715 - feniljain:fix_completions, r=jonas-sc…
15ff8a5 
…hievink

fix: breaking snippets on typed incomplete suggestions

Possible fix for rust-lang#7929

Fix the case where if a user types `&&42.o`, snippet completion was still applying &&Ok(42). Note this was fixed previously on `&&42.` but this still remained a problem for this case

Previous relevant PR: rust-lang#13517

### Points to help in review:

- The main problem why everything broke on adding an extra `o` was, earlier `dot_receiver` was `42.` which was a `LITERAL` but now `42.o` becomes a `FIELD_EXPR`

- Till now `include_references` was just checking for parent of `LITERAL` and if it was a `REF_EXPR`, but now we consider `FIELD_EXPR` and traverse all of them, finally to reach `REF_EXPR`. If `REF_EXPR` is not found we  just return the original `initial_element`

- We are constructing a new node during `include_references` because if we rely on `dot_receiver` solely we would get `&&42.o` to be replaced with, but we want `&&42` to be replaced with

### Output Video:

https://user-images.githubusercontent.com/49019259/205420166-efbdef78-5b3a-4aef-ab4b-d892dac056a0.mov

Hope everything I wrote makes sense 😅

Also interestingly previous PR's number was `13517` and this PR's number is `13715`, nicee
# for free to join this conversation on GitHub. Already have an account? # to comment
Assignees
No one assigned
Labels
E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion. I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

rustc: Check --dep-info target path apaprocki/rust
2 participants
@flaper87 @blastrock