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

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