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

Unable to run cargo doc over project. #95

Closed
fud opened this issue Jun 21, 2018 · 4 comments
Closed

Unable to run cargo doc over project. #95

fud opened this issue Jun 21, 2018 · 4 comments

Comments

@fud
Copy link

fud commented Jun 21, 2018

I am using this crate indirectly from the stm32f1 crate when I try to document that library I'm getting an error with cortex-m.

cargo doc -p stm32f1 --open

Documenting cortex-m v0.5.2 error:[::task::Poll]` cannot be resolved, ignoring it...
|
note: lint level defined here
--> /Users/billsb/.cargo/registry/src/github.com-1ecc6299db9ec823/cortex-m-0.5.2/src/lib.rs:42:9
|
42 | #![deny(warnings)]
| ^^^^^^^^
= note: #[deny(intra_doc_link_resolution_failure)] implied by #[deny(warnings)]
= note: the link appears in this line:

        [`Poll::Pending`](::task::Poll). The future will *also* register the
                          ^^^^^^^^^^^^

= help: to escape [ and ] characters, just add '' before them like \[ or \]

error: [::task::Context::waker] cannot be resolved, ignoring it...
|
= note: the link appears in this line:

        [`cx.waker()`](::task::Context::waker)). Once a task has been woken up,
                       ^^^^^^^^^^^^^^^^^^^^^^

= help: to escape [ and ] characters, just add '' before them like \[ or \]

error: Could not document cortex-m.`

@japaric
Copy link
Member

japaric commented Jun 21, 2018

Thanks for the report.

    [`Poll::Pending`](::task::Poll). The future will *also* register the

That doc comment doesn't exist in this crate. It actually comes from the core crate (src/libcore/future.rs). What you are experiencing is a bug in rustdoc; it actually looks like a mixture of rust-lang/rust#51468 and rust-lang/rust#51661.

I don't think there's much we can do in this crate to fix this problem though. You could try generating the documentation using an older nightly release using something like cargo +nightly-2018-06-01 doc -p stm32f1 --open (note: haven't tried this myself; you may need to use a different date)

@fud
Copy link
Author

fud commented Jun 21, 2018

Thanks for your detailed reply @japaric I will have a try of that tonight.

@fud fud closed this as completed Jun 21, 2018
@MajorBreakfast
Copy link

Should be fixed with rust-lang/rust#51853

@fud
Copy link
Author

fud commented Jul 10, 2018

I can confirm that this fix did indeed work. Cheers.

japaric added a commit to rust-embedded/cortex-m-semihosting that referenced this issue Aug 26, 2018
by shipping pre-assembled object files. This is the same approach as the one
used in rust-embedded/cortex-m#95
japaric added a commit that referenced this issue Aug 26, 2018
by shipping pre-assembled object files. This is the same approach as the one
used in #95
bors bot added a commit that referenced this issue Aug 26, 2018
108: remove build dependency on arm-none-eabi-gcc r=adamgreig a=japaric

by shipping pre-assembled object files. This is the same approach as the
one used in #95

r? @rust-embedded/cortex-m (anyone)

Co-authored-by: Jorge Aparicio <[email protected]>
bors bot added a commit to rust-embedded/cortex-m-semihosting that referenced this issue Aug 27, 2018
20: remove build dependency on arm-none-eabi-gcc r=adamgreig a=japaric

by shipping pre-assembled object files. This is the same approach as the one
used in rust-embedded/cortex-m#95

r? @rust-embedded/cortex-m (anyone)

Co-authored-by: Jorge Aparicio <[email protected]>
adamgreig pushed a commit that referenced this issue Jan 12, 2022
96: reduce the size of default handlers r=adamgreig a=japaric

this commit replaces the two default handler (DefaultDefaultHandler and
DefaultUserHardFault) by a single handler named `EndlessLoop`. This results in
one less symbol being generated.

Also this new handler uses `compiler_fence` to avoid the "infinite loops w/o
side effects are undef values" bug in LLVM. `compiler_fence` is guaranteed to
generate no code so this reduces the size of the handler (when compiler in
release).

---

As far as I could test this new handler doesn't generate abort instructions when
optimized so it seems like a safe replacement. If we are feeling paranoid then
once #95 we could implement EndlessLoop in assembly.

r? @rust-embedded/cortex-m (anyone)

Co-authored-by: Jorge Aparicio <[email protected]>
adamgreig pushed a commit that referenced this issue Jan 12, 2022
95: [RFC] remove build dependency on arm-none-eabi-gcc (binary blob alternative) r=japaric a=japaric

Before this commit we used gcc to assemble external assembly files into object
files that we linked into our Rust program.

This commit drops the dependency on gcc by shipping the already assembled object
files with this crate source code.

---

This is an alternative to RFC #91 that doesn't require a breaking change or
adding a new Cargo feature and can be implemented right now.

See #91 for the rationale of dropping the dependency on gcc.

This approach can be applied to other Cortex-M crates like cortex-m-semihosting
and cortex-m (would subsume RFC #107).

This seems like an overall better approach to me, but before I go opening more
PRs I want to hear your thoughts, @rust-embedded/cortex-m

closes #91

Co-authored-by: Jorge Aparicio <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants