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

fail_ and fail_bounds_check lang items don't belong to libcore #17886

Closed
farcaller opened this issue Oct 9, 2014 · 3 comments
Closed

fail_ and fail_bounds_check lang items don't belong to libcore #17886

farcaller opened this issue Oct 9, 2014 · 3 comments

Comments

@farcaller
Copy link
Contributor

Both fail_ and fail_bounds_check are platform-dependent and the default implementation in libcore makes it impossible to override those.

I can expect fail to be infinite loop or bkpt instruction, it must not pull in error strings and chunks of fmt that are never doing to be displayed.

At least it's reasonable to cfg-guard the implementations, so cross-tool users could build libcore without them.
@farcaller farcaller mentioned this issue Oct 9, 2014
Closed
@huonw huonw added the A-libs label Oct 12, 2014
@farcaller
Copy link
Contributor Author

After discussing this on IRC: the problem is that the code as is doesn't allow error strings and source paths to be optimised away, and that, alongside with fmt chunks, uses significant amount of space.

farcaller added a commit to hackndev/zinc that referenced this issue Oct 24, 2014
@farcaller
Do not strip exception handlers; bloats binaries.
05c8f3c 
This is a temporary solution to allow exceptions
happening while waiting for some resolution at
rust-lang/rust#17886
@bgamari bgamari mentioned this issue Oct 24, 2014
Closed
@bgamari
Copy link
Contributor

bgamari commented Oct 24, 2014

I opened the above pull request as a temporary solution since this issue affects Zinc quite badly. Some of the machines we target have as little as 16kB of RAM; as it stands the moment the user inadvertently incorporates an unoptimizable division into their code they find they have nearly filled a quarter of their device.

bgamari added a commit to bgamari/rust that referenced this issue Oct 24, 2014
@bgamari
libcore: Make fail handlers optional
468e2cd 
Some users have no need for formatted fail messages and really can't
bear the code sizes that they require. See rust-lang#17886.
@steveklabnik
Copy link
Member

Since this bug was filed, fail was changed to painc. There is no panic_ lang item, I don't know if that was also changed. There is a panic_bounds_check, but it calls out to panic_fmt, which is a "weak lang item", meaning that while libcore declares it, it does not define it. A no_std yes core crate which uses panics must define panic_fmt.

As such, I believe this bug can be closed. Let me know if I've missed something!

lnicola pushed a commit to lnicola/rust that referenced this issue Aug 29, 2024
@bors
Auto merge of rust-lang#17886 - Wilfred:prime_caches_quiescent, r=Vey…
df6ce96 
…kril

internal: ServerStatusParams should consider 'prime caches' in quiescent status

Priming caches is a performance win, but it takes a lock on the salsa database and prevents rust-analyzer from responding to e.g. go-to-def requests.

This causes confusion for users, who see the spinner next to rust-analyzer in the VS Code footer stop, so they start attempting to navigate their code.

Instead, set the `quiescent` status in LSP to false during cache priming, so the VS Code spinner persists until we can respond to any LSP request.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@farcaller @steveklabnik @bgamari @huonw