Skip to content

librustc: Remove all uses of ~str from librustc. #14079

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

Closed
wants to merge 1 commit into from

Conversation

pcwalton
Copy link
Contributor

@alexcrichton
Copy link
Member

This is a pretty big inflation in code size, which mostly seems to derive from format!() returning ~str instead of StrBuf. It looks like large chunks of this should get reverted once format!(), so perhaps it would be best to go ahead and make that change?

@pcwalton
Copy link
Contributor Author

It is better to proceed incrementally with large changes like this. Changing format! will have far reaching effects across all modules and will result in an even bigger patch. It is much better to localize the changes to librustc even if that results in some transitionary bloat.

Transitionary bloat is nothing new and we have had lots of it in the past.

@huonw
Copy link
Member

huonw commented May 10, 2014

We could (temporarily) introduce format_! (or something) for going to a StrBuf?

@alexcrichton
Copy link
Member

I agree with the incremental approach, but this doesn't seem very incremental when a huge amount will be reverted. There's a huge amount of calls to to_strbuf() which shouldn't exist once format!() returns the right type.

@pcwalton
Copy link
Contributor Author

It is absolutely incremental. It is localizing the changes to rustc instead of everywhere that format is used.

@pcwalton
Copy link
Contributor Author

format! is used over 200 times in the test cases and over a thousand times in the libraries. Changing all of them at the same time is going to result in a ridiculously huge, ridiculously fragile patch for no reason.

@huonw
Copy link
Member

huonw commented May 10, 2014

(If it wasn't clear, I was suggesting having both the current format! and the new format_! coexisting and just replacing any format!(...).to_strbuf() introduced in this patch with format_!(...).)

@pcwalton
Copy link
Contributor Author

I guess I could do that. I'm not thrilled about having to redo most of a 3,000+-line transitionary patch for a few days of code cleanliness, but whatever.

@pcwalton pcwalton closed this May 10, 2014
@huonw
Copy link
Member

huonw commented May 10, 2014

Despite my suggestion, I'm personally happy with just landing this as is.

@pcwalton pcwalton reopened this May 10, 2014
@pcwalton
Copy link
Contributor Author

Changed to format_strbuf! per @huonw's suggestion. It barely made a difference (another reason why I think it was somewhat pointless), but I guess it'll be easier to copy and paste fix it post-transition. r? @alexcrichton

@alexcrichton
Copy link
Member

As a passing comment, this makes me think that we really may need a formatting tool because your style is far more verbose in terms of number of lines than the existing style. I don't have a preference either way, but I don't like to keep seeing all these changes to flip flop between two styles.

@alexcrichton
Copy link
Member

Closing, subsumed by #14157 and this may help un-stuck bors.

bors pushed a commit to rust-lang-ci/rust that referenced this pull request Apr 22, 2025
This PR fixes issues with the `missing_asserts_for_indexing` lint.
- false positive when the first index is the highest(or equal) value in
a list of indexes:
```rust
pub fn foo(slice: &[i32]) -> i32{
	slice[1] * slice[0]
}
```
- false negative when an assert statement if found after the indexing
operation.
```rust
pub fn bar(slice: &[i32]) -> i32 {
	let product = slice[0] * slice[1];
	assert!(slice.len() > 1);
	product
}
```

examples: https://godbolt.org/z/s7Y47vKdE

closes: rust-lang#14079

changelog: [`missing_asserts_for_indexing`]: ignore asserts found after
indexing, and do not require asserts if the first index is highest.
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 this pull request may close these issues.

4 participants