- 21 6月, 2016 1 次提交
-
-
由 Eduard Burtescu 提交于
-
- 20 6月, 2016 4 次提交
-
-
由 bors 提交于
run rustfmt on rtstartup folder
-
由 bors 提交于
Add regression test for #34194 This pull request adds a regression test for #34194. Closes #34194.
-
由 bors 提交于
fix build for clang 8.0 With 10.12 and XCode 8-beta we got clang 8. Simple addition as clang 8 will build as well.
-
由 bors 提交于
Add short summaries to btree modules Also improve hash_map and hash_set module short summaries. These are missing from [here](https://doc.rust-lang.org/nightly/std/collections/#modules). r? @steveklabnik
-
- 19 6月, 2016 9 次提交
-
-
由 bors 提交于
Add example in docs for `std::thread::panicking`. None
-
由 bors 提交于
Add test case for #22434 Closes #22434
-
由 bors 提交于
Perform `cfg` attribute processing on decorator-generated items Fixes https://users.rust-lang.org/t/unused-attribute-warning-for-custom-derive-attribute/6180. r? @nrc
-
由 bors 提交于
Add test case for #30276 Make sure that treating a DST tuple constructor as a function doesn't ICE. Closes #30276
-
由 Steven Allen 提交于
Closes #22434
-
由 Steven Allen 提交于
Make sure that treating a DST tuple constructor as a function doesn't ICE. Closes #30276
-
由 bors 提交于
Pretty-print attributes on tuple structs and add tests This adds support to the pretty printer to print attributes added to tuple struct elements. Furthermore, it adds a test that makes sure we will print attributes on all variant data types.
-
由 Daan Sprenkels 提交于
-
- 18 6月, 2016 9 次提交
-
-
由 Guillaume Gomez 提交于
-
由 bors 提交于
Fix ICE in memory categorization of tuple patterns Fixes https://github.com/rust-lang/rust/issues/34334 It seems to be ok for `pat_ty` to return `Err` even if type checking is done, because it uses `infcx.node_ty` which is supposed to return `Err` for all kinds of erroneous types so its callers could quickly bail out with `?`. r? @arielb1
-
由 bors 提交于
doc: fix mis-named binding & remove not needed `mut`
-
由 marudor 提交于
-
由 Vadim Petrochenkov 提交于
-
由 Oliver Middleton 提交于
Also improve hash_map and hash_set module short summaries.
-
由 bors 提交于
Fix panic when using debug in rustc When I was using `println!("{:?}")` [here](https://github.com/rust-lang/rust/blob/master/src/librustc_resolve/lib.rs#L1610) and [here](https://github.com/rust-lang/rust/blob/master/src/librustc_typeck/collect.rs#L836), I was able to get into this `unreachache`.
-
由 Corey Farwell 提交于
-
由 bors 提交于
rustdoc: Add stability notices to impl items Also fixes missing stability notices on methods with no docs. For example [`f64::is_positive`](https://doc.rust-lang.org/nightly/std/primitive.f64.html#method.is_positive) is missing its deprecation message.
-
- 17 6月, 2016 17 次提交
-
-
由 bors 提交于
Fixed the `TAGS.rustc.emacs` and `TAGS.rustc.vi` make targets. (They were added to `ctags.mk` in PR #33256, but I guess I must have only tested running `make TAGS.emacs TAGS.rustc.emacs` and not `make TAGS.rustc.emacs` on its own.)
-
由 bors 提交于
Specialize .zip() for efficient slice and slice iteration The idea is to introduce a private trait TrustedRandomAccess and specialize .zip() for random access iterators into a counted loop. The implementation in the PR is internal and has no visible effect in the API Why a counted loop? To have each slice iterator compile to just a pointer, and both pointers are indexed with the same loop counter value in the generated code. When this succeeds, copying loops are readily recognized and replaced with memcpy and addition loops autovectorize well. The TrustedRandomAccess approach works very well on the surface. Microbenchmarks optimize well, following the ideas above, and that is a dramatic improvement of .zip()'s codegen. ```rust // old zip before this PR: bad, byte-for-byte loop // with specialized zip: memcpy pub fn copy_zip(xs: &[u8], ys: &mut [u8]) { for (a, b) in ys.iter_mut().zip(xs) { *a = *b; } } // old zip before this PR: single addition per iteration // with specialized zip: vectorized pub fn add_zip(xs: &[f32], ys: &mut [f32]) { for (a, b) in ys.iter_mut().zip(xs) { *a += *b; } } // old zip before this PR: single addition per iteration // with specialized zip: vectorized (!!) pub fn add_zip3(xs: &[f32], ys: &[f32], zs: &mut [f32]) { for ((a, b), c) in zs.iter_mut().zip(xs).zip(ys) { *a += *b * *c; } } ``` Yet in more complex situations, the .zip() loop can still fall back to its old behavior where phantom null checks throw in fake premature end of the loop conditionals. Remember that a NULL inside Option<(&T, &T)> makes it a `None` value and a premature (in this case) end of the loop. So even if we have 1) an explicit `Some` in the code and 2) the types of the pointers are `&T` or `&mut T` which are nonnull, we can still get a phantom null check at that point. One example that illustrates the difference is `copy_zip` with slice versus Vec arguments. The involved iterator types are exactly the same, but the Vec version doesn't compile down to memcpy. Investigating into this, the function argument metadata emitted to llvm plays the biggest role. As eddyb summarized, we need nonnull for the loop to autovectorize and noalias for it to replace with memcpy. There was an experiment to use `assume` to add a non-null assumption on each of the two elements in the specialized zip iterator, but this only helped in some of the test cases and regressed others. Instead I think the nonnull/noalias metadata issue is something we need to solve separately anyway. These have conditionally implemented TrustedRandomAccess - Enumerate - Zip These have not implemented it - Map is sideeffectful. The forward case would be workable, but the double ended case is complicated. - Chain, exact length semantics unclear - Filter, FilterMap, FlatMap and many others don't offer random access and/or exact length
-
由 Guillaume Gomez 提交于
-
由 Felix S. Klock II 提交于
(They were added to `ctags.mk` in PR #33256, but I guess I must have only tested running `make TAGS.emacs TAGS.rustc.emacs` and not `make TAGS.rustc.emacs` on its own.)
-
由 Erick Tryzelaar 提交于
This adds support to the pretty printer to print attributes added to tuple struct elements. Furthermore, it adds a test that makes sure we will print attributes on all variant data types.
-
由 bors 提交于
Rollup of 4 pull requests - Successful merges: #34298, #34302, #34307, #34312 - Failed merges:
-
由 Manish Goregaokar 提交于
Revert using ? for try! in the libsyntax pretty printer The use of ...?instead of try!(...) in libsyntax makes extracting libsyntax into syntex quite painful since it's not stable yet. This makes backports take a much longer time and causes a lot of problems for the syntex dependencies. Even if it was, it'd take a few release cycles until syntex would be able to use it. Since it's not stable and that this feature is just syntax sugar, it would be most helpful if we could remove it. cc #34311
-
由 Manish Goregaokar 提交于
[MIR] Cache drops for early scope exits Previously we would rebuild all drops on every early exit from a scope, which for code like: ```rust match x { A => return 1, B => return 2, ... C => return 27 } ``` would produce 27 exactly same chains of drops for each return, basically a `O(n*m)` explosion. [This](https://cloud.githubusercontent.com/assets/679122/16125192/3355e32c-33fb-11e6-8564-c37cab2477a0.png) is such a case for a match on 80-variant enum with 3 droppable variables in scope. For [`::core::iter::Iterator::partial_cmp`](https://github.com/rust-lang/rust/blob/6edea2cfda2818f0a76f4bac2d18a30feb54c137/src/libcore/iter/iterator.rs#L1909) the CFG looked like [this](https://cloud.githubusercontent.com/assets/679122/16122708/ce0024d8-33f0-11e6-93c2-e1c44b910db2.png) (after initial SimplifyCfg). With this patch the CFG looks like [this](https://cloud.githubusercontent.com/assets/679122/16122806/294fb16e-33f1-11e6-95f6-16c5438231af.png) instead. Some numbers (overall very small wins, however neither of the crates have many cases which abuse this corner case): | | old time | old rss | new time | new rss | |-------------------------|----------|---------|----------|----------| | core dump | 0.879 | 224MB | 0.871 | 223MB | | core MIR passes | 0.759 | 224MB | 0.718 | 223MB | | core MIR codegen passes | 1.762 | 230MB | 1.442 | 228MB | | core trans | 3.263 | 279MB | 3.116 | 278MB | | core llvm passes | 5.611 | 263MB | 5.565 | 263MB | | std dump | 0.487 | 190MB | 0.475 | 192MB | | std MIR passes | 0.311 | 190MB | 0.288 | 192MB | | std MIR codegen passes | 0.753 | 195MB | 0.720 | 197MB | | std trans | 2.589 | 287MB | 2.523 | 287MB | | std llvm passes | 7.268 | 245MB | 7.447 | 246MB |
-
由 Manish Goregaokar 提交于
Fix issue where rustbuild expected msvc to have ar I made `cc2ar` return an `Option`. r? @alexcrichton
-
由 Manish Goregaokar 提交于
save-analysis: some tweaks
-
由 bors 提交于
Simplify gated cfg checking r? @nrc
-
由 Tshepang Lekhonkhobe 提交于
-
由 Simonas Kazlauskas 提交于
Previously we would rebuild all drops on every early exit from a scope, which for code like: ```rust match x { a => return 1, b => return 2, ... z => return 27 } ``` would produce 27 exactly same chains of drops for each return, a O(n*m) explosion in drops.
-
由 Erick Tryzelaar 提交于
The use of ...?instead of try!(...) in libsyntax makes extracting libsyntax into syntex quite painful since it's not stable yet. This makes backports take a much longer time and causes a lot of problems for the syntex dependencies. Even if it was, it'd take a few release cycles until syntex would be able to use it. Since it's not stable and that this feature is just syntax sugar, it would be most helpful if we could remove it. cc #34311
-
由 Jeffrey Seyfried 提交于
-
由 bors 提交于
Add an abs_path member to FileMap, use it when writing debug info. Fixes #34179. When items are inlined from extern crates, the filename in the debug info is taken from the FileMap that's serialized in the rlib metadata. Currently this is just FileMap.name, which is whatever path is passed to rustc. Since libcore and libstd are built by invoking rustc with relative paths, they wind up with relative paths in the rlib, and when linked into a binary the debug info uses relative paths for the names, but since the compilation directory for the final binary, tools trying to read source filenames will wind up with bad paths. We noticed this in Firefox with source filenames from libcore/libstd having bad paths. This change stores an absolute path in FileMap.abs_path, and uses that if available for writing debug info. This is not going to magically make debuggers able to find the source, but it will at least provide sensible paths.
-