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

Support smaller failure in libcore #14442

Closed
bharrisau opened this issue May 26, 2014 · 3 comments · Fixed by #14451
Closed

Support smaller failure in libcore #14442

bharrisau opened this issue May 26, 2014 · 3 comments · Fixed by #14451

Comments

@bharrisau
Copy link
Contributor

With the reshuffle of libcore (#13851) it is becoming easier to build an embedded project with Rust. I've implemented the new weak failure in Zinc.rs, but as a result the binaries are 5-6kB larger (hackndev/zinc#41).

The two sources of additional size are c_str_to_static_slice pulling in is_utf8 in an assertion (could this be debug_assert?), and the format_args! macro. Trimming these gets the 5-6kB back (i.e. the empty application goes from 7576 bytes to 1888 bytes).

@alexcrichton: I'm not sure the best solution. My limited knowledge of the system suggests having a --cfg flag to compile libcore with stringless failures (maybe --cfg failure_tiny). Just replacing the c_str_to_static_slice with a zero len Slice {data: pointer, len: 0} (we can get the info from the debugger) and passing a zero length string to format_args!.

@alexcrichton
Copy link
Member

The specific case you've mentioned needs to stay as an assert (or return failure), but I believe that the real problem here is that the compiler is invoking these intrinsics with *u8 instead of &str. If the compiler invoked the intrinsics with &str, none of the assertion code would be necessary.

alexcrichton added a commit to alexcrichton/rust that referenced this issue May 27, 2014
This avoids having to perform conversions from `*u8` to `&'static str` which can
suck in a good deal of code.

Closes rust-lang#14442
bors added a commit that referenced this issue May 29, 2014
This avoids having to perform conversions from `*u8` to `&'static str` which can
suck in a good deal of code.

Closes #14442
@bharrisau
Copy link
Contributor Author

Removing the conversion of c-string to Rust strings saved some of the size. There is 1.3kB remaining in assertion messages and file names. And 3.7kB in string formatting from secret_show inclusions from format_args!. I managed to track down where the secret_show functions were being included from the asm, a pointer to the function is included in the Arguments<> passed to the begin_unwind. (It didn't come up as a function call because there is no branch instruction)

@alexcrichton Thanks for your help - is there anything more that can be done? Or is this a will-not-fix thing? For my use I may end up patching failure.rs to pass a blank Arguments and a zero length file name just to cut the size down. Zinc isn't anything more than an experiment at this point, so I'm very grateful for your assistance so far shaving a few kB off.

@alexcrichton
Copy link
Member

I'm all for shaving off what we can, and in general reducing code size. It sounds like the remaining code size is just code in general, so there may not any more low-hanging fruit in terms of code-size. If rust-lang/rfcs#93 is accepted then the footprint of secret_show will likely be reduced to smaller than it is today.

I wouldn't consider this a will-not-fix thing, but we also don't want to compromise too much on the current functionality of libcore. If you find any size-related issues, please definitely feel free to open an issue, I'd love to trim it down to as small as can be!

bors added a commit to rust-lang-ci/rust that referenced this issue Jun 5, 2023
…=Veykril

internal: Implement Structured API for snippets

Fixes rust-lang#11638 (including moving the cursor before the generated type parameter)

Adds `add_tabstop_{before,after}` for inserting tabstop snippets before & after nodes, and `add_placeholder_snippet` for wrapping nodes inside placeholder nodes.

Currently, the snippets are inserted into the syntax tree in `SourceChange::commit` so that snippet bits won't interfere with syntax lookups before completing a `SourceChange`.

It would be preferable if snippet rendering was deferred to after so that rendering can work directly with text ranges, but have left that for a future PR (it would also make it easier to finely specify which text edits have snippets in them).

Another possible snippet variation to support would be a group of placeholders (i.e. placeholders with the same tabstop number) so that a generated item and its uses can be renamed right as it's generated, which is something that is technically supported by the current snippet hack in VSCode, though it's not clear if that's a thing that is officially supported.
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

Successfully merging a pull request may close this issue.

2 participants