- 21 2月, 2013 7 次提交
-
-
由 Luqman Aden 提交于
-
由 Luqman Aden 提交于
-
由 Luqman Aden 提交于
-
由 bors 提交于
r?
-
由 Brian Anderson 提交于
-
由 bors 提交于
Previously check always succeeded because struct type was derived from the matched expression, not the matched pattern. Fix #4849.
-
由 Patrick Walton 提交于
-
- 20 2月, 2013 33 次提交
-
-
由 bors 提交于
Closes #4924 There are some more `Load` calls that could use this, so it's not completely done yet.
-
由 Daniel Micay 提交于
-
由 bors 提交于
It looks like the type for the whole pattern wasn't being written back, so when privacy tried to look it up everything died.
-
由 Daniel Micay 提交于
-
由 bors 提交于
-
由 Daniel Micay 提交于
Closes #4924
-
由 bors 提交于
-
由 Alex Crichton 提交于
-
由 bors 提交于
As far as I can tell, the only reason run-pass/type-use-i1-versus-i8 is trying to do a read is because that code was left over from the original program the issue was found in. When that test is run as part of check-fast, and apparently only in that case, the test blocks indefinitely, which is bad.
-
由 Marvin Löbel 提交于
-
由 bors 提交于
This patch series is doing a couple things with the ultimate goal of removing `#[allow(vecs_implicitly_copyable)]`, although I'm not quite there yet. The main change is passing around `@~str`s in most places, and using `ref`s in others. As far as I could tell, there are no performance changes with these patches, and all the tests pass on my mac.
-
由 Marvin Löbel 提交于
-
由 bors 提交于
Actually a trivial fix. Fixes the issue #4935.
-
由 Erick Tryzelaar 提交于
-
由 Erick Tryzelaar 提交于
-
由 Erick Tryzelaar 提交于
-
由 Erick Tryzelaar 提交于
-
由 Erick Tryzelaar 提交于
-
由 Erick Tryzelaar 提交于
-
由 Erick Tryzelaar 提交于
-
由 Erick Tryzelaar 提交于
-
由 Erick Tryzelaar 提交于
-
由 Erick Tryzelaar 提交于
-
由 Erick Tryzelaar 提交于
-
由 Erick Tryzelaar 提交于
-
由 Erick Tryzelaar 提交于
-
由 Erick Tryzelaar 提交于
-
由 Erick Tryzelaar 提交于
-
由 Erick Tryzelaar 提交于
-
由 Erick Tryzelaar 提交于
-
由 Seo Sanghyeon 提交于
Previously check always succeeded because struct type was derived from the matched expression, not the matched pattern.
-
由 bors 提交于
r? @graydon - This is for greater uniformity (for example, macros that generate tuples). rustc already supported 1-tuple patterns, but there was no way to construct a 1-tuple term. @graydon , as far as your comment on #4898 - it did turn out to be solvable inside the macro (since @luqmana already fixed it using structs instead), but I still think it's a good idea to allow 1-tuples, for uniformity. I don't think anyone is likely to trip over it, and I'm not too worried that it changes the amount of ambiguity.
-
由 Marvin Löbel 提交于
-