- 31 3月, 2015 1 次提交
-
-
由 Niko Matsakis 提交于
-
- 25 3月, 2015 3 次提交
-
-
由 Nick Cameron 提交于
-
由 Nick Cameron 提交于
-
由 Nick Cameron 提交于
This permits all coercions to be performed in casts, but adds lints to warn in those cases. Part of this patch moves cast checking to a later stage of type checking. We acquire obligations to check casts as part of type checking where we previously checked them. Once we have type checked a function or module, then we check any cast obligations which have been acquired. That means we have more type information available to check casts (this was crucial to making coercions work properly in place of some casts), but it means that casts cannot feed input into type inference. [breaking change] * Adds two new lints for trivial casts and trivial numeric casts, these are warn by default, but can cause errors if you build with warnings as errors. Previously, trivial numeric casts and casts to trait objects were allowed. * The unused casts lint has gone. * Interactions between casting and type inference have changed in subtle ways. Two ways this might manifest are: - You may need to 'direct' casts more with extra type information, for example, in some cases where `foo as _ as T` succeeded, you may now need to specify the type for `_` - Casts do not influence inference of integer types. E.g., the following used to type check: ``` let x = 42; let y = &x as *const u32; ``` Because the cast would inform inference that `x` must have type `u32`. This no longer applies and the compiler will fallback to `i32` for `x` and thus there will be a type error in the cast. The solution is to add more type information: ``` let x: u32 = 42; let y = &x as *const u32; ```
-
- 23 3月, 2015 1 次提交
-
-
由 Niko Matsakis 提交于
for `&mut (Trait+'a)` to `&mut (Trait+'b)` if `'a:'b`. Fixes #14985.
-
- 18 3月, 2015 1 次提交
-
-
由 Niko Matsakis 提交于
-
- 17 3月, 2015 1 次提交
-
-
由 Niko Matsakis 提交于
This upcast coercion currently preserves the vtable for the object, but eventually it can be used to create a derived vtable. The upcast coercion is not introduced into method dispatch; see comment on #18737 for information about why. Fixes #18737.
-
- 03 2月, 2015 1 次提交
-
-
由 Jorge Aparicio 提交于
-
- 30 1月, 2015 4 次提交
-
-
由 Eduard Burtescu 提交于
-
由 Eduard Burtescu 提交于
-
由 Eduard Burtescu 提交于
-
由 Eduard Burtescu 提交于
-
- 20 1月, 2015 1 次提交
-
-
由 Seo Sanghyeon 提交于
-
- 07 1月, 2015 1 次提交
-
-
由 Sean McArthur 提交于
fmt::Show is for debugging, and can and should be implemented for all public types. This trait is used with `{:?}` syntax. There still exists #[derive(Show)]. fmt::String is for types that faithfully be represented as a String. Because of this, there is no way to derive fmt::String, all implementations must be purposeful. It is used by the default format syntax, `{}`. This will break most instances of `{}`, since that now requires the type to impl fmt::String. In most cases, replacing `{}` with `{:?}` is the correct fix. Types that were being printed specifically for users should receive a fmt::String implementation to fix this. Part of #20013 [breaking-change]
-
- 06 1月, 2015 2 次提交
-
-
由 Jorge Aparicio 提交于
-
由 Jorge Aparicio 提交于
-
- 04 1月, 2015 1 次提交
-
-
由 Jorge Aparicio 提交于
-
- 30 12月, 2014 1 次提交
-
-
由 Niko Matsakis 提交于
-
- 29 12月, 2014 4 次提交
-
-
由 Huon Wilson 提交于
-
由 Huon Wilson 提交于
This makes sty only 32 bytes on machines with 64-bit pointers.
-
由 Huon Wilson 提交于
This cuts the ty_bare_fn variant to 48 bytes rather than 56. There doesn't seem to be a noticable memory usage decrease from this.
-
由 Huon Wilson 提交于
This current inflates memory use more than 3 times.
-
- 23 12月, 2014 2 次提交
-
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
type of a fn item or a fn pointer, which are now differentiated. Introduce coercion from fn item to fn pointer.
-
- 22 12月, 2014 1 次提交
-
-
由 Niko Matsakis 提交于
-
- 20 12月, 2014 1 次提交
-
-
由 Eduard Burtescu 提交于
-
- 19 12月, 2014 3 次提交
-
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
have such a silly over-engineered interface.
-
由 Niko Matsakis 提交于
Fix bug in higher-ranked code that would sometimes leak skolemized regions and/or cause incorrect results.
-
- 15 12月, 2014 1 次提交
-
-
由 Niko Matsakis 提交于
-
- 14 12月, 2014 1 次提交
-
-
由 Jorge Aparicio 提交于
-
- 12 12月, 2014 1 次提交
-
-
由 Nick Cameron 提交于
-
- 04 12月, 2014 1 次提交
-
-
由 Niko Matsakis 提交于
-
- 27 11月, 2014 1 次提交
-
-
由 Steve Klabnik 提交于
Sister pull request of https://github.com/rust-lang/rust/pull/19288, but for the other style of block doc comment.
-
- 19 11月, 2014 3 次提交
-
-
由 Eduard Burtescu 提交于
-
由 Eduard Burtescu 提交于
-
由 Eduard Burtescu 提交于
-
- 18 11月, 2014 1 次提交
-
-
由 Nick Cameron 提交于
[breaking-change] Insert an `&` to fix
-
- 08 11月, 2014 1 次提交
-
-
由 Niko Matsakis 提交于
Make TyTrait embed a `TraitRef`, so that when we extend TraitRef, it naturally carries over to object types. I wanted to embed an `Rc<TraitRef>`, but I was foiled by the current static rules, which prohibit non-Sync values from being stored in static locations. This means that the constants for `ty_int` and so forth cannot be initialized.
-
- 21 10月, 2014 1 次提交
-
-
由 Niko Matsakis 提交于
Also: 1. stop eagerly coercing from `[T, ..n]` to `[T]` only do so if requested. 2. permit error to be interact more freely. Fixes #17178.
-