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#4183. Needed for #5656.
r? @catamorphism
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.
- 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#4183. Needed for #5656.
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.
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.
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 #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.
Performing a deep copy isn't ever desired for a persistent data
structure, and it requires a more complex implementation to do
correctly. A deep copy needs to check for cycles to avoid an infinite
loop.
Performing a deep copy isn't ever desired for a persistent data
structure, and it requires a more complex implementation to do
correctly. A deep copy needs to check for cycles to avoid an infinite
loop.
Addresses #5544 and #5770, as well as a comment left in the documentation of `from_str_bytes_common`, so that there is now an option to ignore underscores.
A number like 0b1_1111_1111 == 511 would be parsed to Some(255u8) rather than None
by from_str_common, since 255 * 2 + 1 == 255 (mod 256) so the overflow wasn't detected.
Only applied to conversions where the radix was a power of 2, and where all digits
repeated.
Closes#5770.
Currently error messages say ``mismatched types: expected `uint` but found `[uint * 10]` (expected uint but found vector)`` rather than `[uint, .. 10]`.
r? @brson In my WIP on rustpkg, I was calling driver code that calls
LLVMRustWriteOutputFile more than once. This was making LLVM
unhappy, since that function has code that initializes the
command-line options for LLVM, and I guess you can't do that more
than once. So, check if they've already been initialized.
This adds two generic data types, `Ratio` and `Cmplx` (and some aliases for useful instances, e.g. `Ratio<int>` and `Cmplx<f64>`), and basic arithmetic support, as well as `.to_str` (for both) and `.from_str` (for rational).
The complex number implementation doesn't solve #1284 other than getting something into the libraries, specifically it doesn't even try to address C interop. If the complex part of this gets merged, maybe it's worth closing that issue and reopening more specific issue(s) about the failings.
The implementations can be fleshed out when the numeric traits stabilise (and trait inheritance works).
