- 10 9月, 2018 7 次提交
-
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
-
- 09 9月, 2018 9 次提交
-
-
由 bors 提交于
proc_macro::Group::span_open and span_close Before this addition, every delimited group like `(`...`)` `[`...`]` `{`...`}` has only a single Span that covers the full source location from opening delimiter to closing delimiter. This makes it impossible for a procedural macro to trigger an error pointing to just the opening or closing delimiter. The Rust compiler does not seem to have the same limitation: ```rust mod m { type T = } ``` ```console error: expected type, found `}` --> src/main.rs:3:1 | 3 | } | ^ ``` On that same input, a procedural macro would be forced to trigger the error on the last token inside the block, on the entire block, or on the next token after the block, none of which is really what you want for an error like above. This commit adds `group.span_open()` and `group.span_close()` which access the Span associated with just the opening delimiter and just the closing delimiter of the group. Relevant to Syn as we implement real error messages for when parsing fails in a procedural macro: https://github.com/dtolnay/syn/issues/476. ```diff impl Group { fn span(&self) -> Span; + fn span_open(&self) -> Span; + fn span_close(&self) -> Span; } ``` Fixes #48187 r? @alexcrichton
-
由 bors 提交于
rustc_codegen_llvm: don't assume offsets are always aligned. Fixes #53728 by taking into account not just overall type alignment and the field's alignment when determining whether a field is aligned or not ("packed"), but also the field's offset within the type. Previously, rustc assumed that the offset was always at least as aligned as `min(struct.align, field.align)`. However, there's no real reason to have that assumption, and it obviously can't always be true after we implement `#[repr(align(N), pack(K))]`. There's also a case today where that assumption is not true, involving niche discriminants in enums: Suppose that we have the code in #53728: ```Rust #[repr(u16)] enum DeviceKind { Nil = 0, } #[repr(packed)] struct DeviceInfo { endianness: u8, device_kind: DeviceKind, } struct Wrapper { device_info: DeviceInfo, data: u32 } ``` Observe the layout of `Option<Wrapper>`. It has an alignment of 4 because of the `u32`. `device_info.device_kind` is a good niche field to use, which means the enum ends up with this layout: ``` size = 8 align = 4 fields = [ { offset=1, type=u16 } // discriminant, .<Some>.device_info.device_kind ] ``` And here we have an discriminant with alignment 2 (`u16`) but offset 1.
-
由 David Tolnay 提交于
-
由 bors 提交于
rustc_resolve: only prepend CrateRoot to a non-keyword segment. Fixes #53770 by treating `use` paths as absolute in a finer-grained manner, specifically: ```rust use {a, crate::b, self::c, super::d}; ``` Used to be interpreted as if it were (when `uniform_paths` is not enabled): ```rust use ::{a, crate::b, self::c, super::d}; ``` With this PR, the `CrateRoot` pseudo-keyword indicating an absolute path is only inserted when the first path segment is found (if it's not a keyword), i.e. the example behaves like: ```rust use {::a, crate::b, self::c, super::d}; ``` This should (finally) make `use {path};` fully equivalent to `use path;`. r? @petrochenkov cc @cramertj @joshtriplett @nikomatsakis
-
由 bors 提交于
Fix incorrect outer function type parameter message Fix #51303.
-
由 David Tolnay 提交于
-
由 bors 提交于
Improve messages for un-closed delimiter errors
-
由 bors 提交于
Skip a shared borrow of a immutable local variables issue #53643 r? @nikomatsakis
-
由 bors 提交于
Optimize miri checking of integer array/slices This pull request implements the optimization described in #53845 (the `E-easy` part of that issue, not the refactoring). Instead of checking every element of an integral array, we can check the whole memory range at once. r? @RalfJung
-
- 08 9月, 2018 24 次提交
-
-
由 bors 提交于
#53576 Renaming TyAnon -> TyOpaque Fixes #53576
-
由 bors 提交于
Rollup of 10 pull requests Successful merges: - #53315 (use `NonZeroU32` in `newtype_index!`macro, change syntax) - #53932 ([NLL] Remove base_place) - #53942 (Rewrite `precompute_borrows_out_of_scope` for fewer hash table lookups.) - #53973 (Have rust-lldb look for the rust-enabled lldb) - #53981 (Implement initializer() for FileDesc) - #53987 (rustbuild: allow configuring llvm version suffix) - #53993 (rustc_resolve: don't record uniform_paths canaries as reexports.) - #54007 (crates that provide a `panic_handler` are exempt from the `unused_extern_crates` lint) - #54040 (update books for next release) - #54050 (Update `petgraph` dependency to 0.4.13 to fix build with nightly)
-
由 kennytm 提交于
use `NonZeroU32` in `newtype_index!`macro, change syntax Various improvements to the `newtype_index!` macro: - Use `NonZeroU32` so that `Option<T>` is cheap - More ergonomic helper method, no need to import `Idx` trait all the time - Improve syntax to use `struct` keyword so that ripgrep works to find type def'n Fixes https://github.com/rust-lang/rust/issues/50337 I'm curious to see if this passes tests =)
-
由 kennytm 提交于
Update `petgraph` dependency to 0.4.13 to fix build with nightly I wanted to build Rust from source using a local nightly compiler, but I was unable to get `bootstrap` to compile due to a naming conflict with the `find_map` function. This PR updates the `petgraph` dependency of `bootstrap` to 0.4.13, fixing the issue.
-
由 kennytm 提交于
update books for next release
-
由 kennytm 提交于
crates that provide a `panic_handler` are exempt from the `unused_extern_crates` lint fixes the *first* false positive reported in #53964
-
由 kennytm 提交于
rustc_resolve: don't record uniform_paths canaries as reexports. Fixes #53691, fixes #53484.
-
由 kennytm 提交于
rustbuild: allow configuring llvm version suffix Fixes #53852 by allowing user to install different versions of rust to the same sysroot.
-
由 kennytm 提交于
Implement initializer() for FileDesc Here was my initial issue: ```rust use std::process::{Command}; fn main() { let output = Command::new("curl").arg("-s").arg("http://ovh.net/files/100Mio.dat").output(); println!("{:?}", output.unwrap().stdout.len()); } ``` ``` ~/stuff ❯❯❯ time ./dwl 104857600 ./dwl 16.22s user 1.80s system 23% cpu 1:15.24 total ``` ```rust use std::process::{Command, Stdio}; fn main() { let child = Command::new("curl").arg("-s").arg("http://ovh.net/files/100Mio.dat").stdout(Stdio::piped()).spawn(); let output = child.unwrap().wait_with_output().unwrap(); println!("{:?}", output.stdout.len()); } ``` ``` ~/stuff ❯❯❯ time ./dwl2 104857600 ./dwl2 0.64s user 2.18s system 5% cpu 53.072 total ``` As you can see the first version is spending much more time in userland and also uses more cpu. With the help of @programble, @talchas and @habnabit on the rust IRC, we discovered that the slow version uses two pipes, one for `stdin` and one for `stderr` and in that case it polls when going through [this function](https://github.com/rust-lang/rust/blob/master/src/libstd/sys/unix/pipe.rs#L82). The polling calls `read_to_end` on the pipes repetitively and this results in zeroing its internal buffer each time. To avoid this zeroing, `FileDesc` needs to implement `initializer`. We see no reason why it [wouldn't work with uninitialized memory](https://doc.rust-lang.org/1.26.1/src/std/io/mod.rs.html#534) so this PR fixes that. Here is some tracing of the slow program: ![image](https://user-images.githubusercontent.com/147585/45133180-ed8a2d80-b161-11e8-9ec7-09979ec96145.png) versus the fast program: ![image](https://user-images.githubusercontent.com/147585/45133216-0c88bf80-b162-11e8-908e-ff81d59239fb.png) I have not tested the change yet but will try to build it tomorrow.
-
由 kennytm 提交于
Have rust-lldb look for the rust-enabled lldb We're shipping a rust-enabled lldb, but the "lldb" executable is not installed into the "bin" directory by rustup. See the discussion in https://github.com/rust-lang-nursery/rustup.rs/pull/1492 for background on this decision. There, we agreed to have rust-lldb prefer the rust-enabled lldb if it is installed. This patch changes rust-lldb to look in the sysroot and use the lldb found there, if any. See issue #48168
-
由 kennytm 提交于
Rewrite `precompute_borrows_out_of_scope` for fewer hash table lookups. It now does one hash table lookup per basic block, instead of one per statement. This is worthwhile because this function is hot for NLL builds of `ucd`. I haven't measured the effect of this yet because I'm having trouble doing optimized builds of rustc that are suitable for profiling (#53916). I will do an online perf run instead. r? @nikomatsakis
-
由 kennytm 提交于
[NLL] Remove base_place This function was supposed to make `Box` less special. But * I think that the consensus is that MIR borrowck is going to fully special case `Box` * It wasn't implemented correctly, it's looking at the type of the wrong `Place`, resulting in weird behaviour: ```rust #![feature(nll)] type A = Box<i32>; // If this is changed to another type then this will compile. pub fn foo(x: Box<(String, A)>) { let a = x.0; // This will compile if these lines are swapped let b = x.1; } ``` r? @nikomatsakis
-
由 bors 提交于
stabilize #[panic_handler] closes #44489 ### Update(2018-09-07) This was proposed for stabilization in https://github.com/rust-lang/rust/issues/44489#issuecomment-398965881 and its FCP with disposition to merge / accept is nearly over. The summary of what's being stabilized can be found in https://github.com/rust-lang/rust/issues/44489#issuecomment-416645946 Documentation PRs: - Reference. https://github.com/rust-lang-nursery/reference/pull/362 - Nomicon. https://github.com/rust-lang-nursery/nomicon/pull/75 --- `#[panic_implementation]` was implemented recently in #50338. `#[panic_implementation]` is basically the old `panic_fmt` language item but in a less error prone (\*) shape. There are still some issues and questions to sort out around this feature (cf. #44489) but this PR is meant to start a discussion about those issues / questions with the language team. (\*) `panic_fmt` was not type checked; changes in its function signature caused serious, silent binary size regressions like the one observed in #43054 Some unresolved questions from #44489: > Should the Display of PanicInfo format the panic information as "panicked at 'reason', > src/main.rs:27:4", as "'reason', src/main.rs:27:4", or simply as "reason". The current implementation formats `PanicInfo` as the first alternative, which is how panic messages are formatted by the `std` panic handler. The `Display` implementation is more than a convenience: `PanicInfo.message` is unstable so it's not possible to replicate the `Display` implementation on stable. > Is this design compatible, or can it be extended to work, with unwinding implementations for > no-std environments? I believe @whitequark made more progress with unwinding in no-std since their last comment in #44489. Perhaps they can give us an update? --- Another unresolved question is where this feature should be documented. The feature currently doesn't have any documentation. cc @rust-lang/lang cc @jackpot51 @alevy @phil-opp
-
由 Gabriel Majeri 提交于
This fixes building `bootstrap` using a local Rust nightly.
-
由 bors 提交于
Trait impl show docs Fixes #51834. <img width="1440" alt="screen shot 2018-06-29 at 00 14 33" src="https://user-images.githubusercontent.com/3050060/42063323-6e6e8cc8-7b31-11e8-88ef-4dd2229df76c.png"> (You can see both commit changes in the screenshot
😄 ) r? @QuietMisdreavus -
由 Gabriel Majeri 提交于
Instead of checking every element, we can check the whole memory range at once.
-
由 bors 提交于
do not propagate closure requirements if we can prove them locally Fixes #53570 cc @mikhail-m1 -- you're the one who last touched this code r? @pnkfelix
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
This allows it to print out the "late-bound regions" from the closure context more easily. Besides, all the state that is being printed it is private to the `UniversalRegions`.
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
-
由 Eduard-Mihai Burtescu 提交于
-
由 steveklabnik 提交于
-