Doc fixes for 0.6 incoming #5552
Closed
Conversation
This file contains hidden or 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
I intend to do some big refactoring and don't want to deal w/ std just now
The bots were showing a segfault that I can't reproduce. Assuming it's varargs related so let's not use printf
No more mapping uv structs to Rust structs
This is an internal interface. I want to use rt::io for public interfaces.
Can make turnaround of testing changes to core/std/syntax much faster.
I can already see these are going to get massive. Putting them into multiple files.
TESTARGS=--newrt make check-stage1-rpass Conflicts: src/rt/rustrt.def.in
I don't want any global one-time initalization functions because that will make embedding harder.
… environment, and return pointer
I'm making this change because the _reverse suffix is more commonly used in libcore/libstd.
This is the first step in refactoring the deriving code in libsyntax. No code is changed, just rearranged.
…trans_call, r=graydon Refactor trans_call to separate out the translation of the arguments, environment, and return pointer. Towards rust-lang#3678. r? @brson
the assert_eq! macro compares its arguments and fails if they're not equal. It's more informative than fail_unless!, because it explicitly writes the given and expected arguments on failure.
The version recognition was failing for version 1.11, thinking the minor version was 1 rather than 11.
As per rust-lang#2521. Inlining seems to improve performance slightly: Inlined Not Inlined x86: 13.5482 14.4112 x86_64: 17.4712 18.0696 (Average of 5 runs timed with `time`) ```Rust fn foo() -> int { int::from_str(~"28098").unwrap() } fn main() { for 1000000.times { foo(); foo(); foo(); foo(); foo(); } } ``` All run on: Linux 3.2.0-0.bpo.4-amd64 #1 SMP Debian 3.2.35-2~bpo60+1 x86_64 GNU/Linux The MIPS and ARM bits I didn't inline since I'm not as familiar with them and I also can't test them. All green on try.
Conflicts: src/libcore/rt/context.rs src/libcore/rt/sched.rs src/libcore/rt/thread.rs src/libcore/rt/uv.rs
r? There are a lot of commits here, but not all that much substance. Mostly just refactoring. I started sketching out the beginnings of a very simple I/O API in `core::rt::io` that represents I/O streams as a single `Stream` trait instead of `Reader` / `Writer` pairs. This seems to be the more common pattern (at least this is how the .NET BCL does it) and it seems to me that separate readers and writers would make duplex streams very awkward. Regardless, I don't intend to go very far down the I/O API design road without some mailing list discussion. I've also started on the uv bindings for file I/O but haven't gotten very far. Also hooked up the new scheduler to `rust_start` and the compiletest driver. 70% of run-pass test cases already pass, but I wouldn't read too much into that. I also split the direct, low-level uv bindings in two so that the scheduler can have its own set, leaving `std::net` on its own.
Just some editing-to-reflect-reality on release notes and manual.
The reasoning for doing it this way is that it's much easier to transition method-by-method to the `Map` API than trying to do the migration all at once. I found an issue unrelated to my changes in one of the run-fail tests - if it uses `LinearMap`, it still fails but exits with 0. I xfailed it for now and opened [an issue](rust-lang#5512), because it's not caused by these changes.
This removes some explicit implementations of `Eq` in favor of `#[deriving(Eq)]` and derives `Clone` for a few core types.
`let v = [24, ..1000];` now more or less emits the same IR as:
```Rust
let mut i = 0;
while i < 1000 {
v[i] = 24;
i += 1;
}
```
LLVM will still turn it into a memset if possible with optimization on.
Kills some warnings, and implements str::each_char_reverse so that it actually iterates. The test case wasn't detecting a failure, since the loop body was never executed.
This currently requires workarounds for the borrow checker not being flow-sensitive for `LinearMap` and `TrieMap`, but it can already be expressed for `TreeMap` and `SmallIntMap` without that.
In order to mitigate typo of target-triples, error notification of unsupported target triples which defined in mk/platform.mk added. minor fix for arm-linux-androideabi added.
…r=brson The version recognition was failing for pandoc version 1.11, thinking the minor version was 1 rather than 11, and thus not building the documentation.
Added notes explaining how [expr, ..expr] form is used, targeted at
individuals like me who thought it was more general and handled
dynamic repeat expressions. (I left a TODO for this section in a
comment, but perhaps that is bad form for the manual...)
Added example of `do` syntax with a function of arity > 1; yes, one
should be able to derive this from the text above it, but it is still
a useful detail to compare and contrast against the arity == 1 case.
Added example of using for expression over a uint range, since someone
who is most used to write `for(int i; i < lim; i++) { ... }` will
likely want to know how to translate that form (regardless of whether
it happens to be good style or not for their use-case).
Added note about the semi-strange meaning of "fixed size" of vectors
in the vector type section.
flip1995
pushed a commit
to flip1995/rust
that referenced
this pull request
Dec 20, 2020
…gle-binding, r=ebroto Fixing a false positive for the `match_single_binding` lint rust-lang#5552 This is a fix for a false positive in the `match_single_binding` lint when using `#[cfg()]` on a branch. It is sadly a bit hacky but maybe the best solution as rust removes the other branch from the AST before we can even validate it. This fix looks at the code snippet itself and returns if it includes another thick arrow `=>` besides the one matching arm we found. This can again cause false negatives if someone has the following code: ```rust match x { // => <-- Causes a false negative _ => 1, } ``` I thought about making the code more complex and maybe validating against other things like the `#[cfg()]` macro but I believe that this is the best solution. This has basically switched the issue from a false positive to a false negative in a very specific case. I'm happy to make some changes if you have any suggestions 🙃. --- Fixes rust-lang#5552 changelog: Fixed a false positive in the `match_single_binding` lint with `#[cfg()]` macro
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.
No description provided.