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.

Sign up for GitHub

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

Jump to bottom

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

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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in 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