Skip to content

Rollup of 11 pull requests - #35893

Closed
eddyb wants to merge 25 commits into
rust-lang:masterfrom
eddyb:rollup
Closed

Rollup of 11 pull requests#35893
eddyb wants to merge 25 commits into
rust-lang:masterfrom
eddyb:rollup

Conversation

munyariand others added 25 commits August 11, 2016 10:01
Issue rust-lang#35799 as a part of issue rust-lang#35233
?r jonathandturner
Fixesrust-lang#35797.
Signed-off-by: Johannes Löthberg <johannes@kyriasis.com>
Based on following what happens in CString::new("string literal"):
1. Using `Into<Vec<u8>>`, a Vec is allocated with capacity exactly equal
to the string's input length.
2. By `v.push(0)`, the Vec is grown to twice capacity, since it was full.
3. By `v.into_boxed_slice()`, the Vec capacity is shrunk to fit the length again.
If we use `.reserve_exact(1)` just before the push, then we avoid the
capacity doubling that we're going to have to shrink anyway.
Growing by just 1 byte means that the step (2) is less likely to have to
move the memory to a larger allocation chunk, and that the step (3) does
not have to reallocate.
It used to say "Furtheremore" instead of "Furthermore".
This fixesrust-lang#35849, a regression introduced by the typeck refactoring
around TyNever/!.
…urner
New format for E0426
Issue rust-lang#35799 as a part of issue rust-lang#35233
r? jonathandturner
…umeGomez
Indicate where `core::result::IntoIter` is created.
None
…r=alexcrichton
Check that executable file is in-tree before failing tidy check
I silenced stdout and stderr for ls-files, not sure if that's appropriate (is `make tidy` intended to give debugging information)? Otherwise it prints each file it find to stdout/stderr, which currently prints nothing (only executable files are checked).
I have not done major testing regarding the behavior of ls-files when the file is ignored, but judging by the man page everything should be fine.
I've duplicated the code which makes the path git-friendly from the `Cargo.lock` checking code; I can extract that into a common helper if wanted (it's only two lines).
Fixesrust-lang#35689.
cstring: avoid excessive growth just to 0-terminate
Based on following what happens in CString::new("string literal"):
1. Using `Into<Vec<u8>>`, a Vec is allocated with capacity exactly equal
to the string's input length.
2. By `v.push(0)`, the Vec is grown to twice capacity, since it was full.
3. By `v.into_boxed_slice()`, the Vec capacity is shrunk to fit the length again.
If we use `.reserve_exact(1)` just before the push, then we avoid the
capacity doubling that we're going to have to shrink anyway.
Growing by just 1 byte means that the step (2) is less likely to have to
move the memory to a larger allocation chunk, and that the step (3) does
not have to reallocate.
Addresses part of rust-lang#35838
Fix "Furthermore" Typo in String Docs
It used to say "Furtheremore" instead of "Furthermore".
typeck: use NoExpectation to check return type of diverging fn
Fixesrust-lang#35849.
Thanks @eddyb.
@rust-highfive

Copy link
Copy Markdown
Contributor

r? @brson

(rust_highfive has picked a reviewer for you, use r? to override)

@eddyb

Copy link
Copy Markdown
ContributorAuthor

@bors r+ p=1

@bors

bors commented Aug 22, 2016

Copy link
Copy Markdown
Collaborator

📌 Commit dd5137b has been approved by eddyb

@bors

bors commented Aug 22, 2016

Copy link
Copy Markdown
Collaborator

⌛ Testing commit dd5137b with merge aaad88b...

@bors

bors commented Aug 22, 2016

Copy link
Copy Markdown
Collaborator

💔 Test failed - auto-mac-64-opt

@eddyb

Copy link
Copy Markdown
ContributorAuthor

Ughhh - and I did check that travis passed on each PR.

@eddybeddyb closed this Aug 22, 2016
@CentrilCentril added the rollup A PR which is a rollup label Oct 24, 2019
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

rollupA PR which is a rollup

Projects

None yet

Development

Successfully merging this pull request may close these issues.

14 participants

@eddyb@rust-highfive@bors@brson@Centril@munyari@GuillaumeGomez@tvladyslav@Mark-Simulacrum@kyrias@frewsxcv@bluss@CryZe@petrochenkov