Initial stub for unicode case folding #5821
Closed
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
also, updates test cases a bit
I filled out better descriptions for all of the neccesary functions.
Iterate over lines in a series of files. API (mostly) adopted from Python's fileinput module.
…atamorphism When I submitted rust-lang#5659, it apparently caused some test failures. Then, because I left it in my incoming rather than making a new branch, I deleted my commit. Let's try this again, this time, with its own branch so that I don't screw it up. r?
…docs, r=catamorphism I filled out better descriptions for all of the necessary functions. r?
As per https://github.com/mozilla/rust/wiki/Note-wanted-libraries. Iterates over lines in a series of files, e.g. a basic `cat` ```rust use std::fileinput; fn main() { for fileinput::input |line| { io::println(line); } } ``` The API is essentially a subset of [Python's fileinput module](http://docs.python.org/3.3/library/fileinput.html), although the lack of default arguments and global mutable state means that there are extra functions to handle a few different cases (files from command line arguments, files from a vector, accessing current filename/line number). A few points that possibly require adjustment: - Most functions take vectors of `Path` (well, `Option<Path>`) rather than just `~str`, since this seems safer, and allows finer control without the number of different functions/methods increasing exponentially. - `pathify` has a stupid name. - I'm not quite sure how to mock tests that require external files: the tests in `libcore/io.rs` seem to indicate using a `tmp` subdirectory, so that's what I did, but I can't reliably build rust on this computer to test (sorry! although I have run the tests in just `fileinput.rs` after creating `./tmp/` manually). - The documentation I've written seems pretty crappy and not particularly clear. - Only UTF8 files are supported.
This implements the clone interface for tuples and adds a test to match. The implementation is only on tuples that have elements that are themselves clone-able. This should allow for `#[deriving(Clone)] on nominal types that contain tuples somewhere.
With --opt-level=3, this version runs in 0.014s on my machine, compared to 0.252s for the previous version. Mostly due to the #[inline] on get().
…sing, r=jbclements Changes the parser to parse all streams into token-trees before hitting the parser proper, in preparation for hygiene. As an added bonus, it appears to speed up the parser (albeit by a totally imperceptible 1%). Also, many comments in the parser. Also, field renaming in token-trees (readme->forest, cur->stack).
This naming is free now that `oldmap` has finally been removed, so this is a search-and-replace to take advantage of that. It might as well be called `HashMap` instead of being named after the specific implementation, since there's only one. SipHash distributes keys so well that I don't think there will ever be much need to use anything but a simple hash table with open addressing. If there *is* a better way to do it, it will probably be better in all cases and can just be the default implementation. A cuckoo-hashing implementation combining a weaker hash with SipHash could be useful, but that won't be as general purpose - you would need to write a separate fast hash function specialized for the type to really take advantage of it (like taking a page from libstdc++/libc++ and just using the integer value as the "hash"). I think a more specific naming for a truly alternative implementation like that would be fine, with the nice naming reserved for the general purpose container.
As per [the 0.6 release notes](https://github.com/mozilla/rust/wiki/Doc-detailed-release-notes#06-april-2013) single-element tuples are legal. I spotted a couple of places in the documentation that said otherwise, and propose these changes to them.
…=catamorphism A small typo in debuginfo.rs related to the u16 type.
…atamorphism This removes some of the easier instances of mutable fields where the explicit self can just become `&mut self` along with removing some unsafe blocks which aren't necessary any more now that purity is gone. Most of rust-lang#4568 is done, except for [one case](https://github.com/alexcrichton/rust/blob/less-mut-fields/src/libcore/vec.rs#L1754) where it looks like it has to do with it being a `const` vector. Removing the unsafe block yields: ``` /Users/alex/code/rust2/src/libcore/vec.rs:1755:12: 1755:16 error: illegal borrow unless pure: creating immutable alias to const vec content /Users/alex/code/rust2/src/libcore/vec.rs:1755 for self.each |e| { ^~~~ /Users/alex/code/rust2/src/libcore/vec.rs:1757:8: 1757:9 note: impure due to access to impure function /Users/alex/code/rust2/src/libcore/vec.rs:1757 } ^ error: aborting due to previous error ``` I also didn't delve too much into removing mutable fields with `Cell` or `transmute` and friends.
Currently submodules are using the git protocol. Git protocol is blocked by certain corporate networks which makes it difficult to sync the submodules. Replacing the git protocol with https in order to sync the submodules.
Currently submodules are using the git protocol. Git protocol is blocked by certain corporate networks which makes it difficult to sync the submodules. Replacing the git protocol with https in order to sync the submodules.
The old help text reads "clear the screen", but :clear seems intended to do something completely different. I'm not sure what the intent is. If it's really supposed to clear the screen, not only does it not clear the screen, it does something completely different.
```
rusti> fn foo() { println("called foo!") }
()
rusti> foo();
called foo!
()
rusti> :clear
rusti> foo();
<anon>:34:0: 34:3 error: unresolved name: `foo`.
<anon>:34 foo();
```
Per the contributor guidelines, here's the reason there's no testcase: it's a comment string.
`uint::range_step` or `int::range_step` causes overflow or underflow as following.
code:
```rust
fn main() {
for uint::range_step(3, 0, -2) |n| {
println(fmt!("%u", n));
}
}
```
output:
```
3
1
18446744073709551615
18446744073709551613
...
```
This commit fixes this behavior as follows.
```
3
1
```
…mber of ways. - In a TraitRef, use the self type consistently to refer to the Self type: - trait ref in `impl Trait<A,B,C> for S` has a self type of `S`. - trait ref in `A:Trait` has the self type `A` - trait ref associated with a trait decl has self type `Self` - trait ref associated with a supertype has self type `Self` - trait ref in an object type `@Trait` has no self type - Rewrite `each_bound_traits_and_supertraits` to perform substitutions as it goes, and thus yield a series of trait refs that are always in the same 'namespace' as the type parameter bound given as input. Before, we left this to the caller, but this doesn't work because the caller lacks adequare information to perform the type substitutions correctly. - For provided methods, substitute the generics involved in the provided method correctly. - Introduce TypeParameterDef, which tracks the bounds declared on a type parameter and brings them together with the def_id and (in the future) other information (maybe even the parameter's name!). - Introduce Subst trait, which helps to cleanup a lot of the repetitive code involved with doing type substitution. - Introduce Repr trait, which makes debug printouts far more convenient. Fixes rust-lang#4183. Needed for rust-lang#5656.
It was simpler to just give the variants a value instead of listing out all the cases for (*self, *other) in a match statement or writing spaghetti code. This makes the `cmp` method easier to use with FFI too, since you're a cast away from an idiomatic C comparator function. It would be fine implemented another way though.
…sts, r=nikomatsakis Cleanup substitutions and treatment of generics around traits in a number of ways - In a TraitRef, use the self type consistently to refer to the Self type: - trait ref in `impl Trait<A,B,C> for S` has a self type of `S`. - trait ref in `A:Trait` has the self type `A` - trait ref associated with a trait decl has self type `Self` - trait ref associated with a supertype has self type `Self` - trait ref in an object type `@Trait` has no self type - Rewrite `each_bound_traits_and_supertraits` to perform substitutions as it goes, and thus yield a series of trait refs that are always in the same 'namespace' as the type parameter bound given as input. Before, we left this to the caller, but this doesn't work because the caller lacks adequare information to perform the type substitutions correctly. - For provided methods, substitute the generics involved in the provided method correctly. - Introduce TypeParameterDef, which tracks the bounds declared on a type parameter and brings them together with the def_id and (in the future) other information (maybe even the parameter's name!). - Introduce Subst trait, which helps to cleanup a lot of the repetitive code involved with doing type substitution. - Introduce Repr trait, which makes debug printouts far more convenient. Fixes rust-lang#4183. Needed for rust-lang#5656. r? @catamorphism
Follow-up of rust-lang#5760: Add syntax highlight for `/*! doc */` or `//! doc`.
This leaves the default lint modes at `warn`, but now the unused variable and dead assignment warnings are configurable on a per-item basis. As described in rust-lang#3266, this just involved carrying around a couple ids to pass over to `span_lint`. I personally would prefer to keep the `_` prefix as well. This closes rust-lang#3266.
See my [post](https://mail.mozilla.org/pipermail/rust-dev/2013-April/003518.html) on the mailing list for details. Also: * 3.2 is newer than 3.2svn, so I changed the ordering. (3.2svn is the version used between 3.2 and 3.3.) * 3.3svn is added. This is the version you currently get from compiling LLVM trunk. * 3.3 is added. 3.3 is not released yet, but this is the version used by http://llvm.org/apt/.
"driver/rustc.rs" does not exist anymore
|
Urg, wrong target branch |
flip1995
pushed a commit
to flip1995/rust
that referenced
this pull request
Sep 24, 2020
option_if_let_else - distinguish pure from impure else expressions Addresses partially rust-lang#5821. changelog: improve the lint `option_if_let_else`. Suggest `map_or` or `map_or_else` based on the else expression purity.
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.