Skip to content
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

rustdoc: Called Option::unwrap() on a None value #17736

Closed
ghmlee opened this issue Oct 3, 2014 · 3 comments · Fixed by #17796
Closed

rustdoc: Called Option::unwrap() on a None value #17736

ghmlee opened this issue Oct 3, 2014 · 3 comments · Fixed by #17796
Labels
T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.

Comments

@ghmlee
Copy link

ghmlee commented Oct 3, 2014

Error:

task '<main>' failed at 'called `Option::unwrap()` on a `None` value', /private/tmp/rust-GCum/rust-
0.11.0/src/libcore/option.rs:265                                                                  
make: *** [all] Error 101

Test case:

extern crate rustdoc;

use rustdoc::html::markdown::Markdown;

fn main() {
    let markdown = "# title";
    let html = format!("{}", Markdown(markdown.as_slice()));
    println!("{}", html);
}
@sfackler
Copy link
Member

sfackler commented Oct 3, 2014

Backtrace:

task '<main>' failed at 'called `Option::unwrap()` on a `None` value', /Users/rustbuild/src/rust-buildbot/slave/nightly-mac/build/src/libcore/option.rs:278
stack backtrace:
   1:        0x105c62029 - rt::backtrace::imp::write::h5e81d8e6d0d10e01RPq
   2:        0x105c65555 - failure::on_fail::h68caae8756025d31v6q
   3:        0x105eed845 - unwind::begin_unwind_inner::h7bb0299ab4bd6f7cPQd
   4:        0x105eed503 - unwind::begin_unwind_fmt::hcfef2e4d8e502ed7hOd
   5:        0x105eed212 - rust_begin_unwind
   6:        0x105f4165c - failure::begin_unwind::hc194be7392de8abeank
   7:        0x105f3fe90 - atomic::AtomicBool::store::hbd4446643535e8ecSpj
   8:        0x1023a080e - html::markdown::render::header::hedb865dc06ef23a5Gwl
   9:        0x1024be22f - parse_block
  10:        0x1024bd2e4 - hoedown_document_render
  11:        0x10239eae6 - html::markdown::render::hae163b8349037f8cZnl
  12:        0x1023a86d2 - html::markdown::Markdown<'a>.fmt..Show::fmt::hcbaaf55fd0b67af6DWl
  13:        0x10228401e - fmt::secret_show::h7556523823418219885
  14:        0x105f4ad2f - fmt::write::hdb7f07cec2399131lQy
  15:        0x105f4ab4c - fmt::Arguments<'a>.Show::fmt::h5160d95c5f4620085Hy
  16:        0x105f4ad2f - fmt::write::hdb7f07cec2399131lQy
  17:        0x105bffeba - fmt::format::h7b71c05068bcfa34PBq
  18:        0x102283db2 - main::h75e2f69b8b19e349gaa
  19:        0x1022c0aba - start::closure.8595
  20:        0x105f5162c - rust_try_inner
  21:        0x105f51616 - rust_try
  22:        0x105eeabf7 - unwind::try::heb45a9f3ad06986fxFd
  23:        0x105eeaa6c - task::Task::run::hcd92ee740e9bb36dMVc
  24:        0x1022c090e - start::h9fa01a403bf2217eake
  25:        0x1022c0759 - lang_start::h83801431a7a0e072tje
  26:        0x102283f2f - main

@kmcallister kmcallister changed the title Called Option::unwrap() on a None value rustdoc: Called Option::unwrap() on a None value Oct 4, 2014
@kmcallister kmcallister added the T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. label Oct 4, 2014
@tomjakubowski
Copy link
Contributor

FWIW you can avoid this by first calling rustdoc::html::markdown::reset_headers(), which initializes the thread local key used_header_map. It may make sense to call reset_headers if the key is not set at the top of render, I'll whip up a quick PR.

@ghmlee
Copy link
Author

ghmlee commented Oct 5, 2014

Thanks @tomjakubowski

tomjakubowski added a commit to tomjakubowski/rust that referenced this issue Oct 6, 2014
Previously, external code might call `markdown::render()` without having
called `markdown::reset_headers()`, meaning the TLS key
`used_header_map` was unset.  Now `markdown::render()` ensures that
`used_header_map` is set by calling `reset_headers` if necessary.

Fix rust-lang#17736
bors added a commit that referenced this issue Oct 6, 2014
…ichton

Previously, external code might call `markdown::render()` without having
called `markdown::reset_headers()`, meaning the TLS key
`used_header_map` was unset.  Now `markdown::render()` ensures that
`used_header_map` is set by calling `reset_headers` if necessary.

Fix #17736
bors added a commit that referenced this issue Sep 6, 2015
RalfJung pushed a commit to RalfJung/rust that referenced this issue Aug 1, 2024
feat(ide-completion): explictly show `async` keyword on `impl trait` methods

OLD:

<img width="676" alt="image" src="https://github.com/user-attachments/assets/f6fa626f-6b6d-4c22-af27-b0755e7a6bf8">

Now:

<img width="684" alt="image" src="https://github.com/user-attachments/assets/efbaac0e-c805-4dd2-859d-3e44b2886dbb">

---

This is an preparation for rust-lang/rust-analyzer#17719.

```rust
use std::future::Future;

trait DesugaredAsyncTrait {
    fn foo(&self) -> impl Future<Output = usize> + Send;
    fn bar(&self) -> impl Future<Output = usize> + Send;
}

struct Foo;

impl DesugaredAsyncTrait for Foo {
    fn foo(&self) -> impl Future<Output = usize> + Send {
        async { 1 }
    }

    //
    async fn bar(&self) -> usize {
        1
    }
}

fn main() {
    let fut = Foo.bar();
    fn _assert_send<T: Send>(_: T) {}
    _assert_send(fut);
}
```

If we don't distinguish `async` or not. It would be confusing to generate sugared version `async fn foo ....` and original form `fn foo`  for `async fn in trait` that is defined in desugar form.
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants