- 03 7月, 2018 3 次提交
- 02 7月, 2018 23 次提交
-
-
由 bors 提交于
Did you mean to block nightlies on clippy? Discussion: https://gitter.im/rust-lang/WG-clippy?at=5b073b6597a0361fb760cdc2 r? @alexcrichton did I forget anything? cc @nrc @Manishearth
-
由 bors 提交于
Raise an error if gcov profiling and incremental compilation are both enabled Fixes #50203.
-
由 Oliver Schneider 提交于
-
由 Oliver Schneider 提交于
-
由 bors 提交于
Make `BTreeMap::clone()` not allocate when cloning an empty tree. r? @Gankro CC @porglezomp
-
由 bors 提交于
Use in-tree libbacktrace on Fuchsia cc @abarth r? @alexcrichton (welcome back!
😄 ) -
由 Zack M. Davis 提交于
(The present author fears not being knowledgeable enough to rewrite the comments unilaterally; merely calling it out is a lazy half-measure, but at least doesn't actively make things worse the way an ill-informed rewrite would.)
-
由 Zack M. Davis 提交于
For the HirIdification initiative #50928.
-
由 bors 提交于
add modifier keyword spans to hir::Visibility; improve unreachable-pub, private-no-mangle lint suggestions #50455 pointed out that the unreachable-pub suggestion for brace-grouped `use`s was bogus; #50476 partially ameliorated this by marking the suggestion as `Applicability::MaybeIncorrect`, but this is the actual fix. Meanwhile, another application of having spans available in `hir::Visibility` is found in the private-no-mangle lints, where we can now issue a suggestion to use `pub` if the item has a more restricted visibility marker (this seems much less likely to come up in practice than not having any visibility keyword at all, but thoroughness is a virtue). While we're there, we can also add a helpful note if the item does have a `pub` (but triggered the lint presumably because enclosing modules were private). ![hir_vis](https://user-images.githubusercontent.com/1076988/42018064-ca830290-7a65-11e8-9c4c-48bc846f861f.png) r? @nrc cc @Manishearth
-
由 Nicholas Nethercote 提交于
-
由 bors 提交于
Update liblibc This updates the libc submodule
-
由 bors 提交于
Loosened rules involving statics mentioning other statics Before this PR, trying to mention a static in any way other than taking a reference to it caused a compile-time error. So, while ```rust static A: u32 = 42; static B: &u32 = &A; ``` compiles successfully, ```rust static A: u32 = 42; static B: u32 = A; // error ``` and ```rust static A: u32 = 42; static B: u32 = *&A; // error ``` are not possible to express in Rust. On the other hand, introducing an intermediate `const fn` can presently allow one to do just that: ```rust static A: u32 = 42; static B: u32 = foo(&A); // success! const fn foo(a: &u32) -> u32 { *a } ``` Preventing `const fn` from allowing to work around the ban on reading from statics would cripple `const fn` almost into uselessness. Additionally, the limitation for reading from statics comes from the old const evaluator(s) and is not shared by `miri`. This PR loosens the rules around use of statics to allow statics to evaluate other statics by value, allowing all of the above examples to compile and run successfully. Reads from extern (foreign) statics are however still disallowed by miri, because there is no compile-time value to be read. ```rust extern static A: u32; static B: u32 = A; // error ``` This opens up a new avenue of potential issues, as a static can now not just refer to other statics or read from other statics, but even contain references that point into itself. While it might seem like this could cause subtle bugs like allowing a static to be initialized by its own value, this is inherently impossible in miri. Reading from a static causes the `const_eval` query for that static to be invoked. Calling the `const_eval` query for a static while already inside the `const_eval` query of said static will cause cycle errors. It is not possible to accidentally create a bug in miri that would enable initializing a static with itself, because the memory of the static *does not exist* while being initialized. The memory is not uninitialized, it is not there. Thus any change that would accidentally allow reading from a not yet initialized static would cause ICEs. Tests have been modified according to the new rules, and new tests have been added for writing to `static mut`s within definitions of statics (which needs to fail), and incremental compilation with complex/interlinking static definitions. Note that incremental compilation did not need to be adjusted, because all of this was already possible before with workarounds (like intermediate `const fn`s) and the encoding/decoding already supports all the possible cases. r? @EddyB
-
由 bors 提交于
Rollup of 7 pull requests Successful merges: - #51511 (Stabilize Iterator::flatten in 1.29, fixes #48213.) - #51853 (Fix some doc links) - #51890 (Fix inconsequential typo in GlobalAlloc doc example) - #51920 (use literal span for concrete type suggestion) - #51921 (improve the error message when `#[panic_implementation]` is missing) - #51922 (rename the llvm-tools component to llvm-tools-preview and tweak its image) - #51961 (Fix typo in /src/librustc_resolve/lib.rs) Failed merges: r? @ghost
-
由 Pietro Albini 提交于
Fix typo in /src/librustc_resolve/lib.rs absoluate -> absolute
-
由 Pietro Albini 提交于
rename the llvm-tools component to llvm-tools-preview and tweak its image as per https://github.com/rust-lang/rust/issues/49584#issuecomment-401217483 r? @alexcrichton or @Mark-Simulacrum
-
由 Pietro Albini 提交于
improve the error message when `#[panic_implementation]` is missing closes #51341 r? @nagisa cc @phil-opp
-
由 Pietro Albini 提交于
use literal span for concrete type suggestion Fixes #51874. r? @estebank
-
由 Pietro Albini 提交于
Fix inconsequential typo in GlobalAlloc doc example
-
由 Pietro Albini 提交于
Fix some doc links The futures crate CI always fails because of these intra doc links. I hope that this will fix this issue. r? @steveklabnik @cramertj Edit: I added @steveklabnik as reviewer because this PR also adjusts a link in `src/libstd/error.rs`
-
由 Pietro Albini 提交于
Stabilize Iterator::flatten in 1.29, fixes #48213. This PR stabilizes [`Iterator::flatten`](https://doc.rust-lang.org/nightly/std/iter/trait.Iterator.html#method.flatten) in *version 1.29* (1.28 goes to beta in 10 days, I don't think there's enough time to land it in that time, but let's see...). Tracking issue is: #48213. cc @bluss re. itertools. r? @SimonSapin ping @pietroalbini -- let's do a crater run when this passes CI :)
-
由 bors 提交于
Speed up compilation of large constant arrays This is a different approach to #51672 as suggested by @oli-obk. Rather than write each repeated value one-by-one, we write the first one and then copy its value directly into the remaining memory. With this change, the [toy program](https://github.com/rust-lang/rust/blob/c2f4744d2db4e162df824d0bd0b093ba4b351545/src/test/run-pass/mir_heavy_promoted.rs) goes from 63 seconds to 19 seconds on my machine. Edit: Inlining `Size::bytes()` saves an additional 6 seconds dropping the total time to 13 seconds on my machine. Edit2: Now down to 2.8 seconds. r? @oli-obk cc @nnethercote @EddyB
-
由 est31 提交于
-
由 Zack M. Davis 提交于
It was pointed out in review that the glob-exported underscore-suffixed convention for `Spanned` HIR nodes is no longer preferred: see February 2016's #31487 for AST's migration away from this style towards properly namespaced NodeKind enums. This concerns #51968.
-
- 01 7月, 2018 14 次提交
-
-
由 bors 提交于
NLL: bad error message when converting anonymous lifetime to `'static` Contributes to #46983. This PR doesn't introduce fantastic errors, but it should hopefully lay some groundwork for diagnostic improvements. r? @nikomatsakis
-
由 David Wood 提交于
-
由 David Wood 提交于
-
由 Niko Matsakis 提交于
-
由 David Wood 提交于
-
由 David Wood 提交于
-
由 David Wood 提交于
-
由 David Wood 提交于
-
由 David Wood 提交于
-
由 David Wood 提交于
Constraints are now being categorized, sorted and the error labelled. Categorization needs a bit of work.
-
由 Wesley Wiser 提交于
-
由 David Wood 提交于
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
-