Rollup of 12 pull requests #59289
Closed
Rollup of 12 pull requests #59289
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
There are two moments when a BufRead object needs to empty it's internal buffer: - In a seek call; - In a read call when all data in the internal buffer had been already consumed and the output buffer has a greater or equal size than the internal buffer. In both cases, the buffer was not being properly emptied, but only marked as consumed (self.pos = self.cap). That should be no problem if the inner reader is only Read, but if it is Seek as well, then it's possible to access the data in the buffer by using the seek_relative method. In order to prevent this from happening, both self.pos and self.cap should be set to 0. Two test cases were added to detect that failure: - test_buffered_reader_invalidated_after_read - test_buffered_reader_invalidated_after_seek Both tests are very similar to each other. The inner reader contains the following data: [5, 6, 7, 0, 1, 2, 3, 4]. The buffer capacity is 3 bytes. - First, we call fill_buffer, which loads [5, 6, 7] into the internal buffer, and then consume those 3 bytes. - Then we either read the 5 remaining bytes in a single read call or we move to the end of the stream by calling seek. In both cases the buffer should be emptied to prevent the previous data [5, 6, 7] from being read. - We now call seek_relative(-2) and read two bytes, which should give us the last 2 bytes of the stream: [3, 4]. Before this commit, the the seek_relative method would consider that we're still in the range of the internal buffer, so instead of fetching data from the inner reader, it would return the two last bytes that were incorrectly still in the buffer: [6, 7]. Therefore, the test would fail. Now, when seek_relative is called the buffer is empty. So the expected data [3, 4] is fetched from the inner reader and the test passes.
…);` and potentially instantiated at different types. (Updated to reflect changes in diagnostic output and compiletest infrastructure.)
Co-authored-by: Stephan Schauerte <stephan.schauerte@gmail.com>
The use-case of `todo!()` macro is to be a much easier to type alternative to `unimplemented!()` macro.
Add todo!() macro The primary use-case of `todo!()` macro is to be a much easier to type alternative to `unimplemented!()` macro. EDIT: hide unpopular proposal about re-purposing unimplemented <details> However, instead of just replacing `unimplemented!()`, it gives it a more nuanced meaning: a thing which is intentionally left unimplemented and which should not be called at runtime. Usually, you'd like to prevent such cases statically, but sometimes you, for example, have to implement a trait only some methods of which are applicable. There are examples in the wild of code doing this thing, and in this case, the current message of `unimplemented`, "not *yet* implemented" is slightly misleading. With the addition of TODO, you have three nuanced choices for a `!`-returning macro (in addition to a good-old panic we all love): * todo!() * unreachable!() * unimplemented!() Here's a rough guideline what each one means: - `todo`: use it during development, as a "hole" or placeholder. It might be a good idea to add a pre-commit hook which checks that `todo` is not accidentally committed. - `unreachable!()`: use it when your code can statically guarantee that some situation can not happen. If you use a library and hit `unreachable!()` in the library's code, it's definitely a bug in the library. It's OK to have `unreachable!()` in the code base, although, if possible, it's better to replace it with compiler-verified exhaustive checks. - `unimplemented!()`: use it when the type checker forces you to handle some situation, but there's a contract that a callee must not actually call the code. If you use a library and hit `unimplemented!()`, it's probably a bug in your code, though it *could* be a bug in the library (or library docs) as well. It is ok-ish to see an `unimplemented!()` in real code, but it usually signifies a clunky, eyebrow-rising API. </details>
…constraints-on-bindings-too, r=nikomatsakis extra testing of how NLL handles wildcard type `_` test that wildcard type `_` is not duplicated by `type Foo<X> = (X, X);` and potentially instantiated at different types when used in type ascriptions in let bindings. (NLL's handling of this for the type ascription *expression form* is currently broken, or at least differs from what AST-borrowck does. I'll file a separate bug about that. Its not something critical to address since that expression is guarded by `#![feature(type_ascription)]`.) cc rust-lang#55748
dbg!() without parameters Fixes rust-lang#57845.
…petrochenkov Lint for redundant imports This is an attempt at solving rust-lang#10178. The changes are suggested by `@petrochenkov`. I need some feedback on how to continue, since I get a lot of false positives in macro invocations in `libcore`. I suspect that the test ``` ... if directive.parent_scope.expansion == Mark::root() { return; } ... ``` is wrong. But I don't know how to check correctly if I am at a macro expansion root – given that this is the reason for the errors in the first place. Todos: - [x] Solve problem with false positives - [x] Turn hard error into warning - [x] Add unit tests Closes rust-lang#10178
Clarify distinction between floor() and trunc() `floor()` rounds towards `-INF`, `trunc()` rounds towards 0. This PR clarifies this in the examples.
…iplett Add new test case for possible bug in BufReader When reading a large chunk from a BufReader, if all the bytes from the buffer have been already consumed, the internal buffer is bypassed entirely. However, it is not invalidated, and it's possible to access its contents using the `seek_relative` method, because it tries to reuse the existing buffer.
…uietMisdreavus Add default keyword handling in rustdoc Fixes rust-lang#58898. r? @QuietMisdreavus
Fix a tiny error in documentation of std::pin. `new_unmoved` must be `mut` for passing to `std::mem::swap`.
Add peer_addr function to UdpSocket Fixes rust-lang#59104 This is my first pull request to Rust, so opening early for some feedback. My biggest question is: where do I add tests? Any comments very much appreciated!
Be more discerning on when to attempt suggesting a comma in a macro invocation Fix rust-lang#58796.
add self to mailmap
…cell-map-split, r=cramertj,Centril Stabilize refcell_map_split feature Closes rust-lang#51476.
|
@bors r+ p=12 |
|
📌 Commit 631534c has been approved by |
bors
added
the
S-waiting-on-bors
|
⌛ Testing commit 631534c with merge bfd08ab511b0825b0462d38da4fa04bbfcb6e248... |
|
💔 Test failed - checks-travis |
bors
added
S-waiting-on-review
|
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
_#57729 (extra testing of how NLL handles wildcard type_)Failed merges:
r? @ghost