- 20 8月, 2018 2 次提交
-
-
由 Dmytro Shynkevych 提交于
-
由 Dmytro Shynkevych 提交于
-
- 19 8月, 2018 1 次提交
-
-
由 Dmytro Shynkevych 提交于
-
- 05 8月, 2018 2 次提交
-
-
由 Dmytro Shynkevych 提交于
-
由 Dmytro Shynkevych 提交于
-
- 04 8月, 2018 3 次提交
-
-
由 bors 提交于
Update clippy r? @kennytm @alexcrichton
-
由 bors 提交于
NLL mentions lifetimes that are not included in printed span(s). Part of #52663. r? @pnkfelix
-
由 Manish Goregaokar 提交于
-
- 03 8月, 2018 27 次提交
-
-
由 bors 提交于
Disable debug sections when optimization flags is set for LLD. Currently LLD does not error when optimization is set and debugging information sections are present. (See discussion at https://reviews.llvm.org/D47901) Using `--strip-debug` along with the `-O` option.
-
由 Oliver Schneider 提交于
-
由 Oliver Schneider 提交于
-
由 Oliver Schneider 提交于
-
由 bors 提交于
NLL: Better Diagnostic When "Later" means "A Future Loop Iteration" Part of #52663. r? @pnkfelix
-
由 Oliver Schneider 提交于
-
由 bors 提交于
check_const: use the same ParamEnv as codegen for statics Fixes at least part of https://github.com/rust-lang/rust/issues/52849 (my CTFE-stress benchmark). Note that I do not know what I am doing here, this is just based on hints from @oli-obk. r? @oli-obk
-
由 bors 提交于
Update tool submodules, update feature unification strategy * Bring in some fixes for `cargo fix` * Update RLS/rustfmt to keep them compiling * Update all tools to [depend on `rustc-workspace-hack`](https://github.com/rust-lang/rust/pull/52919#issuecomment-409802418) * Change how we deal with feature unification amongst these builds.
-
由 Alex Crichton 提交于
Bring in some fixes for `cargo fix` notably
-
由 bors 提交于
Implement a self profiler This is a work in progress implementation of #50780. I'd love feedback on the overall structure and code as well as some specific things: - [The query categorization mechanism](https://github.com/rust-lang/rust/compare/master...wesleywiser:wip_profiling?expand=1#diff-19e0a69c10eff31eb2d16805e79f3437R101). This works but looks kind of ugly to me. Perhaps there's a better way? - [The profiler assumes only one activity can run at a time](https://github.com/rust-lang/rust/compare/master...wesleywiser:wip_profiling?expand=1#diff-f8a403b2d88d873e4b27c097c614a236R177). This is obviously incompatible with the ongoing parallel queries. - [The output code is just a bunch of `format!()`s](https://github.com/rust-lang/rust/compare/master...wesleywiser:wip_profiling?expand=1#diff-f8a403b2d88d873e4b27c097c614a236R91). Is there a better way to generate markdown or json in the compiler? - [The query categorizations are likely wrong](https://github.com/rust-lang/rust/compare/master...wesleywiser:wip_profiling?expand=1#diff-19e0a69c10eff31eb2d16805e79f3437R101). I've marked what seemed obvious to me but I'm sure I got a lot of them wrong. The overhead currently seems very low. Running `perf` on a sample compilation with profiling enabled reveals: ![image](https://user-images.githubusercontent.com/831192/41657821-9775efec-7462-11e8-9e5e-47ec94105d9d.png)
-
由 Wesley Wiser 提交于
-
由 Wesley Wiser 提交于
-
由 Wesley Wiser 提交于
-
由 Wesley Wiser 提交于
-
由 Wesley Wiser 提交于
-
由 Wesley Wiser 提交于
-
由 Wesley Wiser 提交于
-
由 Wesley Wiser 提交于
-
由 Wesley Wiser 提交于
-
由 Wesley Wiser 提交于
-
由 Wesley Wiser 提交于
-
由 Wesley Wiser 提交于
-
由 Wesley Wiser 提交于
-
由 Wesley Wiser 提交于
-
由 bors 提交于
resolve: Implement prelude search for macro paths, implement tool attributes When identifier is macro path is resolved in scopes (i.e. the first path segment - `foo` in `foo::mac!()` or `foo!()`), scopes are searched in the same order as for non-macro paths - items in modules, extern prelude, tool prelude (see later), standard library prelude, language prelude, but with some extra shadowing restrictions (names from globs and macro expansions cannot shadow names from outer scopes). See the comment in `fn resolve_lexical_macro_path_segment` for more details. "Tool prelude" currently contains two "tool modules" `rustfmt` and `clippy`, and is searched immediately after extern prelude. This makes the [possible long-term solution](https://github.com/rust-lang/rfcs/blob/master/text/2103-tool-attributes.md#long-term-solution) for tool attributes exactly equivalent to the existing extern prelude scheme, except that `--extern=my_crate` making crate names available in scope is replaced with something like `--tool=my_tool` making tool names available in scope. The `tool_attributes` feature is still unstable and `#![feature(tool_attributes)]` now implicitly enables `#![feature(use_extern_macros)]`. `use_extern_macros` is a prerequisite for `tool_attributes`, so their stabilization will happen in the same order. If `use_extern_macros` is not enabled, then tool attributes are treated as custom attributes (this is temporary, anyway). Fixes https://github.com/rust-lang/rust/issues/52576 Fixes https://github.com/rust-lang/rust/issues/52512 Fixes https://github.com/rust-lang/rust/issues/51277 cc https://github.com/rust-lang/rust/issues/52269
-
由 bors 提交于
[NLL] Dangly paths for box Special-case `Box` in `rustc_mir::borrow_check`. Since we know dropping a box will not access any `&mut` or `&` references, it is safe to model its destructor as only touching the contents *owned* by the box. ---- There are three main things going on here: 1. The first main thing, this PR is fixing a bug in NLL where `rustc` previously would issue a diagnostic error in a case like this: ```rust fn foo(x: Box<&mut i32>) -> &mut i32 { &mut **x } ``` such code was accepted by the AST-borrowck in the past, but NLL was rejecting it with the following message ([playground](https://play.rust-lang.org/?gist=13c5560f73bfb16d6dab3ceaad44c0f8&version=nightly&mode=release&edition=2015)) ``` error[E0597]: `**x` does not live long enough --> src/main.rs:3:40 | 3 | fn foo(x: Box<&mut i32>) -> &mut i32 { &mut **x } | ^^^^^^^^ - `**x` dropped here while still borrowed | | | borrowed value does not live long enough | note: borrowed value must be valid for the anonymous lifetime #1 defined on the function body at 3:1... --> src/main.rs:3:1 | 3 | fn foo(x: Box<&mut i32>) -> &mut i32 { &mut **x } | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error ``` 2. The second main thing: The reason such code was previously rejected was because NLL (MIR-borrowck) incorporates a fix for issue #31567, where it models a destructor's execution as potentially accessing any borrows held by the thing being destructed. The tests with `Scribble` model this, showing that the compiler now catches such unsoundness. However, that fix for issue #31567 is too strong, in that NLL (MIR-borrowck) includes `Box` as one of the types with a destructor that potentially accesses any borrows held by the box. This thus was the cause of the main remaining discrepancy between AST-borrowck and MIR-borrowck, as documented in issue #45696, specifically in [the last example of this comment](https://github.com/rust-lang/rust/issues/45696#issuecomment-345367873), which I have adapted into the `fn foo` shown above. We did close issue #45696 back in December of 2017, but AFAICT that example was not fixed by PR #46268. (And we did not include a test, etc etc.) This PR fixes that case, by trying to model the so-called `DerefPure` semantics of `Box<T>` when we traverse the type of the input to `visit_terminator_drop`. 3. The third main thing is that during a review of the first draft of this PR, @matthewjasper pointed out that the new traversal of `Box<T>` could cause the compiler to infinite loop. I have adjusted the PR to avoid this (by tracking what types we have previously seen), and added a much needed test of this somewhat odd scenario. (Its an odd scenario because the particular case only arises for things like `struct A(Box<A>);`, something which cannot be constructed in practice.) Fix #45696.
- 02 8月, 2018 5 次提交
-
-
由 bors 提交于
Switch to bootstrapping from 1.29 beta r? @alexcrichton
-
由 bors 提交于
NLL migration in the 2018 edition needs two-phase borrows too! NLL migration in the 2018 edition needs two-phase borrows too! Fix #52967.
-
由 Felix S. Klock II 提交于
Fix #52967.
-
由 Oliver Schneider 提交于
-
由 bors 提交于
enable jemalloc assertions when configured to do so This is essentially a re-submission of the functional part of https://github.com/rust-lang/rust/pull/43648. I was unable to reproduce the issue I had back then, maybe something changed somewhere to no longer trigger the assertion. Fixes https://github.com/rust-lang/rust/issues/44152
-