- 21 8月, 2018 1 次提交
-
-
由 kennytm 提交于
Updated RELEASES.md for 1.29.0 [Rendered](https://github.com/Aaronepower/rust/blob/master/RELEASES.md) r? @Mark-Simulacrum cc @rust-lang/release
-
- 20 8月, 2018 23 次提交
-
-
由 bors 提交于
Add the identity function as core::convert::identity ## New notes This implements rust-lang/rfcs#2306 (see https://github.com/rust-lang/rust/issues/53500). ## Old notes (ignore this in new reviews) Adds the identity function `fn id<T>(x: T) -> T { x }` to core::convert and the prelude. Some motivations for why this is useful are explained in the doc tests. Another is that using the identity function instead of `{ x }` or `|x| x` makes it clear that you intended to use an identity conversion on purpose. The reasoning: + behind adding this to `convert` and not `mem` is that this is an identity *conversion*. + for adding this to the prelude is that it should be easy enough to use that the ease of writing your own identity function or using a closure `|x| x` doesn't overtake that. I've separated this out into two feature gates so that the addition to the prelude can be considered and stabilized separately. cc @bluss
-
由 Mazdak Farrokhzad 提交于
-
由 Manish Goregaokar 提交于
-
由 bors 提交于
try to infer linker flavor from linker name and vice versa This is a second take on PR #50359 that implements the logic proposed in https://github.com/rust-lang/rust/pull/50359#pullrequestreview-116663121 With this change it would become possible to link `thumb*` binaries using GNU's LD on stable as `-C linker=arm-none-eabi-ld` would be enough to change both the linker and the linker flavor from their default values of `arm-none-eabi-gcc` and `gcc`. To link `thumb*` binaries using rustc's LLD on stable `-Z linker-flavor` would need to be stabilized as `-C linker=rust-lld -Z linker-flavor=ld.lld` are both required to change the linker and the linker flavor, but this PR doesn't propose that. We would probably need some sort of stability guarantee around `rust-lld`'s name and availability to make linking with rustc's LLD truly stable. With this change it would also be possible to link `thumb*` binaries using a system installed LLD on stable using the `-C linker=ld.lld` flag (provided that `ld.lld` is a symlink to the system installed LLD). r? @alexcrichton
-
由 bors 提交于
Rename CodeMap/FileMap to SourceMap/SourceFile A first renaming for #51574
-
由 Jorge Aparicio 提交于
-
由 bors 提交于
52985: cause cycle err on inf trait normalization Issue: #52985 - If an existential type is defined, but no user code infers the concrete type behind the existential type, normalization would infinitely recurse on this existential type which is only defined in terms of itself. - Instead of raising an inf recurse error, we cause a cycle error to help highlight that the issue is that the type is only defined in terms of itself. - Three known potential improvements: - If type folding itself was exposed as a query, used by normalization and other mechanisms, cases that would cause infinite recursion would automatically cause a cycle error. - The span for the cycle error should be improved to point to user code that fails to allow inference of the concrete type of the existential type, assuming that this error occurs because no user code can allow inference the concrete type. - A mechanism to extend the cycle error with a helpful note would be nice. Currently, the error is built and maintained by src/librustc/ty/query/plumbing, with no known way to extend the information that the error gets built with. r? @oli-obk
-
由 Donato Sciarra 提交于
-
由 Donato Sciarra 提交于
-
由 Donato Sciarra 提交于
-
由 Donato Sciarra 提交于
-
由 Donato Sciarra 提交于
-
由 Donato Sciarra 提交于
-
由 Donato Sciarra 提交于
-
由 Donato Sciarra 提交于
-
由 Mazdak Farrokhzad 提交于
-
由 bors 提交于
optimize reassignment immutable state This is the "simple fix" when it comes to checking for reassignment. We just shoot for compatibility with the AST-based checker. Makes no attempt to solve #21232. I opted for this simpler fix because I didn't want to think about complications [like the ones described here](https://github.com/rust-lang/rust/issues/21232#issuecomment-412219247). Let's do some profiling measurements. Fixes #53189 r? @pnkfelix
-
由 Mazdak Farrokhzad 提交于
-
由 Mazdak Farrokhzad 提交于
-
由 Mazdak Farrokhzad 提交于
-
由 Mazdak Farrokhzad 提交于
-
由 Mazdak Farrokhzad 提交于
-
- 19 8月, 2018 16 次提交
-
-
由 Niko Matsakis 提交于
now compare-mode can show us the differences
-
由 Niko Matsakis 提交于
We did not seem to have any!
-
由 Niko Matsakis 提交于
Don't iterate over all things that are initialized.
-
由 Niko Matsakis 提交于
-
由 bors 提交于
Implement Unsized Rvalues This PR is the first step to implement RFC1909: unsized rvalues (#48055). ## Implemented - `Sized` is removed for arguments and local bindings. (under `#![feature(unsized_locals)]`) - Unsized locations are allowed in MIR - Unsized places and operands are correctly translated at codegen ## Not implemented in this PR - Additional `Sized` checks: - tuple struct constructor (accidentally compiles now) - closure arguments at closure generation (accidentally compiles now) - upvars (ICEs now) - Generating vtable for `fn method(self)` (ICEs now) - VLAs: `[e; n]` where `n` isn't const - Reduce unnecessary allocations ## Current status - [x] Fix `__rust_probestack` (rust-lang-nursery/compiler-builtins#244) - [x] Get the fix merged - [x] `#![feature(unsized_locals)]` - [x] Give it a tracking issue number - [x] Lift sized checks in typeck and MIR-borrowck - [ ] <del>Forbid `A(unsized-expr)`</del> will be another PR - [x] Minimum working codegen - [x] Add more examples and fill in unimplemented codegen paths - [ ] <del>Loosen object-safety rules (will be another PR)</del> - [ ] <del>Implement `Box<FnOnce>` (will be another PR)</del> - [ ] <del>Reduce temporaries (will be another PR)</del>
-
由 Jorge Aparicio 提交于
-
由 bors 提交于
debug_assert to ensure that from_raw_parts is only used properly aligned This does not help nearly as much as I would hope because everybody uses the distributed libstd which is compiled without debug assertions. For this reason, I am not sure if this is even worth it. OTOH, this would have caught the misalignment fixed by https://github.com/rust-lang/rust/issues/42789 *if* there had been any tests actually using ZSTs with alignment >1 (we have a CI runner which has debug assertions in libstd enabled), and it seems to currently [fail in the rg testsuite](https://ci.appveyor.com/project/rust-lang/rust/build/1.0.8403/job/v7dfdcgn8ay5j6sb). So maybe it is worth it, after all. I have seen the attribute `#[rustc_inherit_overflow_checks]` in some places, does that make it so that the *caller's* debug status is relevant? Is there a similar attribute for `debug_assert!`? That could even subsume `rustc_inherit_overflow_checks`: Something like `rustc_inherit_debug_flag` could affect *all* places that change the generated code depending on whether we are in debug or release mode. In fact, given that we have to keep around the MIR for generic functions anyway, is there ever a reason *not* to handle the debug flag that way? I guess currently we apply debug flags like `cfg` so this is dropped early during the MIR pipeline? EDIT: I learned from @EddyB that because of how `debug_assert!` works, this is not realistic. Well, we could still have it for the rustc CI runs and then maybe, eventually, when libstd gets compiled client-side and there is both a debug and a release build... then this will also benefit users.^^
-
由 Jorge Aparicio 提交于
-
由 Masaki Hara 提交于
-
由 Masaki Hara 提交于
-
由 Masaki Hara 提交于
The paragraph described a case where we can't optimize away repetitive dynamic stack allocation. However, as arielb1 pointed out, it can actually optimizable by dynamically delaying the stack unwinding.
-
由 Masaki Hara 提交于
-
由 Masaki Hara 提交于
-
由 Masaki Hara 提交于
-
由 Masaki Hara 提交于