- 26 3月, 2021 6 次提交
-
-
由 JohnTitor 提交于
-
由 bors 提交于
Allow for reading raw bytes from rustc_serialize::Decoder without unsafe code The current `read_raw_bytes` method requires using `MaybeUninit` and `unsafe`. I don't think this is necessary. Let's see if a safe interface has any performance drawbacks. This is a followup to #83273 and will make it easier to rebase #82183. r? `@cjgillot`
-
由 bors 提交于
Rework rustdoc const type This PR is mostly about two things: 1. Not storing some information in the `clean::Constant` type 2. Using `TyCtxt` in the formatting (which we will need in any case as we move forward in any case). Also: I'm very curious of the perf change in here. Thanks a lot `@danielhenrymantilla` for your `Captures` idea! It allowed me to solve the lifetime issue completely. :) r? `@jyn514`
-
由 bors 提交于
Refactor rustc_resolve::late::lifetimes to resolve per-item There are some changes to tests that I'd like some feedback on; so this is still WIP. The reason behind this change will (hopefully) allow us to (as part of #76814) be able to essentially use the lifetime resolve code to resolve *all* late bound vars (including those of super traits). Currently, it only resolves those that are *syntactically* in scope. In #76814, I'm essentially finding that I would essentially have to redo the passing of bound vars through scopes (i.e. when instantiating a poly trait ref), and that's what this code does anyways. However, to be able to do this (ask super traits what bound vars are in scope), we have to be able to resolve items separately. The first commit is actually partially orthogonal. Essentially removing one use of late bound debruijn indices. Not exactly sure who would be best to review here. Let r? `@nikomatsakis`
-
由 Jack Huey 提交于
-
由 bors 提交于
GenericParam does not need to be a HIR owner. The special case is not required. Universal impl traits design to regular generic parameters, and their content is owned by the enclosing item. Existential (and opaque) impl traits generate their own enclosing item, and are collected through it.
-
- 25 3月, 2021 29 次提交
-
-
由 Niko Matsakis 提交于
-
由 bors 提交于
Update the minimum external LLVM to 10 r? `@nikic`
-
由 Michael Woerister 提交于
-
由 bors 提交于
Revert reverting of stabilizing integer::BITS. Now that `lexical-core` has an updated version that won't break with this stabilization, let's try to stabilize this again. See https://github.com/rust-lang/rust/issues/81654#issuecomment-778564715 Tracking issue with FCP: https://github.com/rust-lang/rust/issues/76904
-
由 bors 提交于
RemoveZsts: don't touch unions This should fix a Miri ICE r? `@RalfJung`
-
由 bors 提交于
coverage bug fixes and optimization support Adjusted LLVM codegen for code compiled with `-Zinstrument-coverage` to address multiple, somewhat related issues. Fixed a significant flaw in prior coverage solution: Every counter generated a new counter variable, but there should have only been one counter variable per function. This appears to have bloated .profraw files significantly. (For a small program, it increased the size by about 40%. I have not tested large programs, but there is anecdotal evidence that profraw files were way too large. This is a good fix, regardless, but hopefully it also addresses related issues. Fixes: #82144 Invalid LLVM coverage data produced when compiled with -C opt-level=1 Existing tests now work up to at least `opt-level=3`. This required a detailed analysis of the LLVM IR, comparisons with Clang C++ LLVM IR when compiled with coverage, and a lot of trial and error with codegen adjustments. The biggest hurdle was figuring out how to continue to support coverage results for unused functions and generics. Rust's coverage results have three advantages over Clang's coverage results: 1. Rust's coverage map does not include any overlapping code regions, making coverage counting unambiguous. 2. Rust generates coverage results (showing zero counts) for all unused functions, including generics. (Clang does not generate coverage for uninstantiated template functions.) 3. Rust's unused functions produce minimal stubbed functions in LLVM IR, sufficient for including in the coverage results; while Clang must generate the complete LLVM IR for each unused function, even though it will never be called. This PR removes the previous hack of attempting to inject coverage into some other existing function instance, and generates dedicated instances for each unused function. This change, and a few other adjustments (similar to what is required for `-C link-dead-code`, but with lower impact), makes it possible to support LLVM optimizations. Fixes: #79651 Coverage report: "Unexecuted instantiation:..." for a generic function from multiple crates Fixed by removing the aforementioned hack. Some "Unexecuted instantiation" notices are unavoidable, as explained in the `used_crate.rs` test, but `-Zinstrument-coverage` has new options to back off support for either unused generics, or all unused functions, which avoids the notice, at the cost of less coverage of unused functions. Fixes: #82875 Invalid LLVM coverage data produced with crate brotli_decompressor Fixed by disabling the LLVM function attribute that forces inlining, if `-Z instrument-coverage` is enabled. This attribute is applied to Rust functions with `#[inline(always)], and in some cases, the forced inlining breaks coverage instrumentation and reports. FYI: `@wesleywiser` r? `@tmandry`
-
由 bors 提交于
Rollup of 8 pull requests Successful merges: - #83041 (stabilize debug_non_exhaustive) - #83349 (Remove Option::{unwrap_none, expect_none}.) - #83420 (Add documentation for rustdoc-gui tests) - #83421 (Add Result::into_err where the Ok variant is the never type) - #83427 (small cleanups in rustc_errors / emitter) - #83434 (Update RELEASES.md) - #83440 (Use intra-doc link in core::cell) - #83442 (LLVMWrapper: attractive nuisance macros) Failed merges: - #83438 (Update RELEASES.md) r? `@ghost` `@rustbot` modify labels: rollup
-
由 Yuki Okushi 提交于
LLVMWrapper: attractive nuisance macros This came up in the review of #83425: it's hard to imagine a use of LLVM_VERSION_LE() or LLVM_VERSION_EQ() that's not asking for trouble when a point release gets created, so let's just discard them to prevent the issue.
-
由 Yuki Okushi 提交于
Use intra-doc link in core::cell ``@rustbot`` label T-doc A-intra-doc-links r? ``@jyn514``
-
由 Yuki Okushi 提交于
Update RELEASES.md This change was backed out in #83412 so we should remove the reference to it from the release notes.
-
由 Yuki Okushi 提交于
small cleanups in rustc_errors / emitter This is either moving code around so it gets called less often or using if let instead of match in a few cases.
-
由 Yuki Okushi 提交于
Add Result::into_err where the Ok variant is the never type Equivalent of #66045 but for the inverse situation where `T: Into<!>` rather than `E: Into<!>`. I'm using the same feature gate name. I can't see why one of these methods would be OK to stabilize but not the other. Tracking issue: #61695
-
由 Yuki Okushi 提交于
Add documentation for rustdoc-gui tests I think a bit of documentation doesn't hurt in this case considering how "out of the ordinary" this is. r? ``@jyn514``
-
由 Yuki Okushi 提交于
Remove Option::{unwrap_none, expect_none}. This removes `Option::unwrap_none` and `Option::expect_none` since we're not going to stabilize them, see https://github.com/rust-lang/rust/issues/62633. Closes #62633
-
由 Yuki Okushi 提交于
stabilize debug_non_exhaustive tracking issue: https://github.com/rust-lang/rust/issues/67364 but it is still an open question whether the other `Debug*` struct's should have a similar method. I would guess that would best be put underneath a new feature gate, as this one seems uncontroversial enough to stabilize as is
-
由 Mara Bos 提交于
-
由 Mara Bos 提交于
-
由 Mara Bos 提交于
-
由 Guillaume Gomez 提交于
-
由 bors 提交于
Use `EvaluatedToOkModuloRegions` whenever we erase regions Fixes #80691 When we evaluate a trait predicate, we convert an `EvaluatedToOk` result to `EvaluatedToOkModuloRegions` if we erased any regions. We cache the result under a region-erased 'freshened' predicate, so `EvaluatedToOk` may not be correct for other predicates that have the same cache key.
-
由 Guillaume Gomez 提交于
-
由 Guillaume Gomez 提交于
-
由 Guillaume Gomez 提交于
-
由 Guillaume Gomez 提交于
-
由 Jack Huey 提交于
-
由 Jack Huey 提交于
This reverts commit 22ae20733515d710c1134600bc1e29cdd76f6b9b.
-
由 Aaron Hill 提交于
Fixes #80691 When we evaluate a trait predicate, we convert an `EvaluatedToOk` result to `EvaluatedToOkModuloRegions` if we erased any regions. We cache the result under a region-erased 'freshened' predicate, so `EvaluatedToOk` may not be correct for other predicates that have the same cache key.
-
由 Augie Fackler 提交于
THis came up in the review of #83425: it's hard to imagine a use of LLVM_VERSION_LE() or LLVM_VERSION_EQ() that's not asking for trouble when a point release gets created, so let's just discard them to prevent the issue.
-
由 Erik Desjardins 提交于
-
- 24 3月, 2021 5 次提交
-
-
由 bors 提交于
2229 migration: Don't try resolve regions before writeback In the analysis use `resolve_vars_if_possible` instead of `fully_resolve`, because we might not have performed regionck yet. Fixes: #83176 r? `@nikomatsakis`
-
由 Deadbeef 提交于
-
由 bors 提交于
Run analyses before thir-tree dumps Fixes #83048
-
由 bors 提交于
Expose str::SplitInclusive in alloc and therefore in std This seems to have been omitted from the beginning when this feature was first introduced in 86bf9629. Most users won't need to name this type which is probably why this wasn't noticed in the meantime. See #83372 for a different but related bug. ### Notes for reviewers I think I have got this right but TBH I am not very familiar with the relationship between core and std and so on. <strike>I also haven't don't any kind of test (not even a build) yet. I will do a local docs build to see that the type now appears in the std docs.</strike> I did a local docs build and it has made this type appear as `std::str::SplitInclusive` as expected The linkification of the return value from `str::split_inclusive` teleports me to the online url for `core::str::SplitInclusive`. I think this may be a rustdoc anomaly (similar to #79630 maybe) but I am not sure. Perhaps it means I haven't done the `std` -> `core` referrence correctly. I made this insta-stable since it seems like simply a bug. Please LMK if that is not right. *(edited to add:)* In particular, IDK how this ought to relate to the (?)current release process.
-
由 bors 提交于
implement `feature(const_generics_defaults)` Implements const generics defaults `struct Example<const N: usize=3>`, as well as a query for getting the default of a given const-parameter's def id. There are some remaining FIXME's but they were specified as not blocking for merging this PR. This also puts the defaults behind the unstable feature gate `#![feature(const_generics_defaults)]`. ~~This currently creates a field which is always false on `GenericParamDefKind` for future use when consts are permitted to have defaults. I'm not sure if this is exactly what is best for adding default parameters, but I mimicked the style of type defaults, so hopefully this is ok.~~ r? `@lcnr`
-