- 11 1月, 2020 12 次提交
-
-
由 Lzu Tao 提交于
-
由 bors 提交于
build-std compatible sanitizer support ### Motivation When using `-Z sanitizer=*` feature it is essential that both user code and standard library is instrumented. Otherwise the utility of sanitizer will be limited, or its use will be impractical like in the case of memory sanitizer. The recently introduced cargo feature build-std makes it possible to rebuild standard library with arbitrary rustc flags. Unfortunately, those changes alone do not make it easy to rebuild standard library with sanitizers, since runtimes are dependencies of std that have to be build in specific environment, generally not available outside rustbuild process. Additionally rebuilding them requires presence of llvm-config and compiler-rt sources. The goal of changes proposed here is to make it possible to avoid rebuilding sanitizer runtimes when rebuilding the std, thus making it possible to instrument standard library for use with sanitizer with simple, although verbose command: ``` env CARGO_TARGET_X86_64_UNKNOWN_LINUX_GNU_RUSTFLAGS=-Zsanitizer=thread cargo test -Zbuild-std --target x86_64-unknown-linux-gnu ``` ### Implementation * Sanitizer runtimes are no long packed into crates. Instead, libraries build from compiler-rt are used as is, after renaming them into `librusc_rt.*`. * rustc obtains runtimes from target libdir for default sysroot, so that they are not required in custom build sysroots created with build-std. * The runtimes are only linked-in into executables to address issue #64629. (in previous design it was hard to avoid linking runtimes into static libraries produced by rustc as demonstrated by sanitizer-staticlib-link test, which still passes despite changes made in #64780). cc @kennytm, @japaric, @firstyear, @choller
-
由 bors 提交于
Rollup of 8 pull requests Successful merges: - #66045 (Add method Result::into_ok) - #67258 (Introduce `X..`, `..X`, and `..=X` range patterns) - #68014 (Unify output of "variant not found" errors) - #68019 (Build compiletest with in-tree libtest) - #68039 (remove explicit strip-hidden pass from compiler doc generation) - #68050 (Canonicalize rustc_error imports) - #68059 (Allow specifying LLVM args in target specifications) - #68075 (rustbuild: Cleanup book generation) Failed merges: - #68089 (Unstabilize `Vec::remove_item`) r? @ghost
-
由 Yuki Okushi 提交于
rustbuild: Cleanup book generation The Cargo book can be generated the same way as the other books.
-
由 Yuki Okushi 提交于
Allow specifying LLVM args in target specifications
-
由 Yuki Okushi 提交于
Canonicalize rustc_error imports r? @Mark-Simulacrum
-
由 Yuki Okushi 提交于
remove explicit strip-hidden pass from compiler doc generation `strip-hidden` is now implied by `--document-private-items` with #67875, so there's no need to specify it anymore.
-
由 Yuki Okushi 提交于
Build compiletest with in-tree libtest This updates compiletest to build in `Mode::ToolStd`, using the locally-built crates for `std` and especially `test`. This way we're immune to unstable differences in the bootstrap compiler crates, whether that's a prior-release stage0 or a current release local rebuild. Fixes #59264. As a minor cleanup, this also removes the unused `llvm_tools` flag.
-
由 Yuki Okushi 提交于
Unify output of "variant not found" errors Fix #49566.
-
由 Yuki Okushi 提交于
Introduce `X..`, `..X`, and `..=X` range patterns Tracking issue: https://github.com/rust-lang/rust/issues/67264 Feature gate: `#![feature(half_open_range_patterns)]` --------------------------- In this PR, we introduce range-from (`X..`), range-to (`..X`), and range-to-inclusive (`..=X`) patterns. These correspond to the `RangeFrom`, `RangeTo`, and `RangeToInclusive` expression forms introduced with the same syntaxes. The correspondence is both syntactic and semantic (in the sense that e.g. a `X..` pattern matching on a scrutinee `s` holds exactly when `(X..).contains(&s)` holds). --------------------------- Noteworthy: - The compiler complexity added with this PR is around 10 lines (discounting new tests, which account for the large PR size). - `...X` is accepted syntactically with the same meaning as `..=X`. This is done primarily to simplify and unify the implementation & spec. If-and-when we decide to make `X...Y` a hard error on a new edition, we can do the same for `...X` patterns as well. - `X...` and `X..=` is rejected syntactically just like it is for the expression equivalents. We should perhaps make these into semantic restrictions (cc @petrochenkov). - In HAIR, these half-open ranges are represented by inserting the max/min values for the approprate types. That is, `X..` where `X: u8` would become `X..=u8::MAX` in HAIR (note the `..=` since `RangeFrom` includes the end). - Exhaustive integer / char matching does not (yet) allow for e.g. exhaustive matching on `0usize..` or `..5usize | 5..` (same idea for `isize`). This would be a substantially more invasive change, and could be added in some other PR. - The issues with slice pattern syntax has been resolved as we decided to use `..` to mean a "rest-pattern" and `[xs @ ..]` to bind the rest to a name in a slice pattern. - Like with https://github.com/rust-lang/rust/pull/35712, which provided `X..Y` range patterns, this is not yet backed up by an RFC. I'm providing this experimental implementation now to have something concrete to discuss. I would be happy to provide an RFC for this PR as well as for #35712 to finalize and confirm the ideas with the larger community. Closes https://github.com/rust-lang/rfcs/issues/947. --------------------------- r? @varkor cc @matthewjasper @oli-obk I would recommend reviewing this (in particular HAIR-lowering and pattern parsing changes) with whitespace changes ignored.
-
由 Yuki Okushi 提交于
Add method Result::into_ok Implementation of https://github.com/rust-lang/rfcs/pull/2799 Tracking issue #61695
-
- 10 1月, 2020 28 次提交
-
-
由 bors 提交于
self-profiling: Support recording query keys This PR makes self-profiling able to record query keys. The implementation is not as efficient as it could be yet (all query keys except for `DefId`s cause string data to be duplicated) and the rendered strings could be nicer too. But the implementation is functional and introduces the basic framework for emitting per-query-invocation event data. I tried to add proper documentation on how everything works. Let me know if more documentation is needed. r? @wesleywiser @Mark-Simulacrum, heads up: This updates `measureme` to 0.7.0 which means that `summarize` on perf.rlo needs to be update accordingly once this is merged.
-
由 Michael Woerister 提交于
-
由 Michael Woerister 提交于
-
由 Michael Woerister 提交于
-
由 Michael Woerister 提交于
-
由 Michael Woerister 提交于
-
由 Michael Woerister 提交于
-
由 Michael Woerister 提交于
self-profile: Switch to new approach for event_id generation that enables query-invocation-specific event_ids.
-
由 Jethro Beekman 提交于
-
由 Mazdak Farrokhzad 提交于
-
由 Mazdak Farrokhzad 提交于
This feature adds `X..`, `..X`, and `..=X` patterns.
-
由 bors 提交于
Rollup of 6 pull requests Successful merges: - #66463 (Point at opaque and closure type definitions in type errors) - #67501 (Reduce special treatment for zsts) - #67820 (Parse the syntax described in RFC 2632) - #67922 (rustc_ast_lowering: misc cleanup & rustc dep reductions) - #68071 (Extend support of `_` in type parameters) - #68073 (expect `fn` after `const unsafe` / `const extern`) Failed merges: r? @ghost
-
由 Mazdak Farrokhzad 提交于
expect `fn` after `const unsafe` / `const extern` Fixes #68062 r? @estebank @petrochenkov cc @Aaron1011
-
由 Mazdak Farrokhzad 提交于
Extend support of `_` in type parameters - Account for `impl Trait<_>`. - Provide a reasonable `Span` for empty `Generics` in `impl`s. - Account for `fn foo<_>(_: _) {}` to suggest `fn foo<T>(_: T) {}`. - Fix #67995. Follow up to #67597.
-
由 Mazdak Farrokhzad 提交于
rustc_ast_lowering: misc cleanup & rustc dep reductions - The first two commits do some code simplification. - The next three do some file splitting (getting `lib.rs` below the 3kloc tidy lint). - The remaining commits reduce the number of `rustc::` imports. This works towards making lowering independent of the `rustc` crate. r? @oli-obk cc @Zoxc
-
由 Mazdak Farrokhzad 提交于
Parse the syntax described in RFC 2632 This adds support for both `impl const Trait for Ty` and `?const Trait` bound syntax from rust-lang/rfcs#2632 to the parser. For now, both modifiers end up in a newly-added `constness` field on `ast::TraitRef`, although this may change once the implementation is fleshed out. I was planning on using `delay_span_bug` when this syntax is encountered during lowering, but I can't write `should-ice` UI tests. I emit a normal error instead, which causes duplicates when the feature gate is not enabled (see the `.stderr` files for the feature gate tests). Not sure what the desired approach is; Maybe just do nothing when the syntax is encountered with the feature gate is enabled? @oli-obk I went with `const_trait_impl` and `const_trait_bound_opt_out` for the names of these features. Are these to your liking? cc #67792 #67794 r? @Centril
-
由 Mazdak Farrokhzad 提交于
Reduce special treatment for zsts addresses https://github.com/rust-lang/rust/pull/67467#discussion_r360650846 cc @RalfJung
-
由 Mazdak Farrokhzad 提交于
Point at opaque and closure type definitions in type errors Fixes #57266, fixes #67117.
-
由 Dylan MacKenzie 提交于
-
由 Dylan MacKenzie 提交于
-
由 Dylan MacKenzie 提交于
-
由 Dylan MacKenzie 提交于
-
由 Dylan MacKenzie 提交于
-
由 Dylan MacKenzie 提交于
-
由 Dylan MacKenzie 提交于
-
由 Dylan MacKenzie 提交于
This means the new syntax will always fail to compile, even when the feature gate is enabled. These checks will be removed in a later PR once the implementation is done.
-
由 Dylan MacKenzie 提交于
The grammar also handles `?const ?Trait` even though this is semantically redundant.
-
由 Dylan MacKenzie 提交于
-