- 23 3月, 2020 28 次提交
-
-
由 Mazdak Farrokhzad 提交于
rustc: keep upvars tupled in {Closure,Generator}Substs. Previously, each closure/generator capture's (aka "upvar") type was tracked as one "synthetic" type parameter in the closure/generator substs, and figuring out where the parent `fn`'s generics end and the synthetics start involved slicing at `tcx.generics_of(def_id).parent_count`. Needing to query `generics_of` limited @davidtwco (who wants to compute some `TypeFlags` differently for parent generics vs upvars, and `TyCtxt` is not available there), which is how I got started on this, but it's also possible that the `generics_of` queries are slowing down `{Closure,Generator}Substs` methods. To give an example, for a `foo::<T, U>::{closure#0}` with captures `x: X` and `y: Y`, substs are: * before this PR: `[T, U, /*kind*/, /*signature*/, X, Y]` * after this PR: `[T, U, /*kind*/, /*signature*/, (X, Y)]` You can see that, with this PR, no matter how many captures, the last 3 entries in the substs (or 5 for a generator) are always the "synthetic" ones, with the last one being the tuple of capture types. r? @nikomatsakis cc @Zoxc
-
由 Mazdak Farrokhzad 提交于
Increase verbosity when suggesting subtle code changes Do not suggest changes that are actually quite small inline, to minimize the likelihood of confusion. Fix #69243.
-
由 Mazdak Farrokhzad 提交于
librustc_codegen_llvm: Replace deprecated API usage
-
由 Mazdak Farrokhzad 提交于
rustc_codegen_llvm: don't generate any type debuginfo for -Cdebuginfo=1. Works towards #69074 by adding more checks for `DebugInfo::Full` in a few places in `rustc_codegen_llvm`, bringing us in line with what `clang -g1` generates (no debuginfo types, nor debuginfo for `static`s). <hr/> My local build's (`debuginfo-level=1`, `debug-assertions=1`) `librustc_driver-*.so` went from just over 1GiB (1019MiB) down to 402MiB. It's still bad, but the `.debug_*` sections themselves (as reported by `objdump`) went from something like 853MiB down to 236MiB, i.e. roughly a 3.6x reduction. <hr/> Sadly, I don't think this is enough to justify *shipping* all of this debuginfo, but now it's more plausible that we could at least *build* with `debuginfo-level=1` *then* strip it. That would give us real backtraces for e.g. ICEs during builds, but I don't know how often that's relevant. We could also look into split DWARF, and maybe have a `rustc-debuginfo` component in `rustup`. There's also the possibility of making it slimmer by omitting parameters to functions, or perhaps some deduplication (I think right now there is no DWARF reuse across CGUs? maybe ThinLTO helps?). r? @michaelwoerister cc @rust-lang/wg-codegen @alexcrichton @Mark-Simulacrum
-
由 bors 提交于
Rollup of 9 pull requests Successful merges: - #69251 (#[track_caller] in traits) - #69880 (miri engine: turn error sanity checks into assertions) - #70207 (Use getentropy(2) on macos) - #70227 (Only display definition when suggesting a typo) - #70236 (resolve: Avoid "self-confirming" import resolutions in one more case) - #70248 (parser: simplify & remove unused field) - #70249 (handle ConstKind::Unresolved after monomorphizing) - #70269 (remove redundant closures (clippy::redundant_closure)) - #70270 (Clean up E0449 explanation) Failed merges: r? @ghost
-
由 Mazdak Farrokhzad 提交于
Clean up E0449 explanation r? @Dylan-DPC
-
由 Mazdak Farrokhzad 提交于
remove redundant closures (clippy::redundant_closure)
-
由 Mazdak Farrokhzad 提交于
handle ConstKind::Unresolved after monomorphizing fixes #70125 r? @bjorn3
-
由 Mazdak Farrokhzad 提交于
parser: simplify & remove unused field r? @petrochenkov
-
由 Mazdak Farrokhzad 提交于
resolve: Avoid "self-confirming" import resolutions in one more case So the idea behind "blacklisted bindings" is that we must ignore some name definitions during resolution because otherwise they cause infinite cycles. E.g. import ```rust use my_crate; ``` would refer to itself (on 2018 edition) without this blacklisting, because `use my_crate;` is the first name in scope when we are resolving `my_crate` here. In this PR we are doing this blacklisting for the case ```rust use same::same; ``` , namely blacklisting the second `same` when resolving the first `same`. This was previously forgotten. Fixes https://github.com/rust-lang/rust/issues/62767
-
由 Mazdak Farrokhzad 提交于
Only display definition when suggesting a typo Closes #70206 r? @Centril
-
由 Mazdak Farrokhzad 提交于
Use getentropy(2) on macos resolves #70179
-
由 Mazdak Farrokhzad 提交于
miri engine: turn error sanity checks into assertions We had these as debug assertions so far to make sure our test suite is clean, but really these are conditions that should never arise and also @EddyB told me to turn non-performance-critical debug assertions into full assertions so here we go. ;) I propose that we do a check-only crater run to make sure this does not actually happen in practice. r? @oli-obk
-
由 Mazdak Farrokhzad 提交于
#[track_caller] in traits Per https://github.com/rust-lang/rust/issues/47809#issuecomment-572791760, this allows the `#[track_caller]` attribute on trait methods. Includes tests for `#[track_caller]` with: * "regular" trait impls * default trait impls * "blanket-tracked" trait impls, where the annotation is in the trait definition and is inherited by "regular" impls of the trait
-
由 bors 提交于
Liberate `rustc_ast_lowering` from `rustc` The whole point of this PR is the very last commit, in which we remove `rustc` as one of `rustc_ast_lowering`'s dependencies, thereby improving `./x.py` parallelism and working towards https://github.com/rust-lang/rust/issues/65031. Noteworthy: - From `rustc::arena` we move logic into `arena`, in particular `declare_arena!`. This is then used in `rustc_ast_lowering` so that lowering has its own separate arena. - Some linting code is unfortunately moved to `rustc_session::lint` cause its used both in `rustc_lint` and `rustc_ast_lowering`, and this is their common dependency. - `rustc_session::CrateDisambiguator` is moved into `rustc_ast` so that `rustc::hir::map::definitions` can be moved into `rustc_hir`, so that `rustc_ast_lowering` can stop referring to `rustc::hir`. r? @Zoxc
-
由 Eduard-Mihai Burtescu 提交于
-
由 Eduard-Mihai Burtescu 提交于
-
由 Eduard-Mihai Burtescu 提交于
-
由 Eduard-Mihai Burtescu 提交于
-
由 Adam Perry 提交于
We can do this now that opt_associated_item doesn't have any panicking paths.
-
由 Adam Perry 提交于
The codegen implementation already works for this, so we're: * propagating track_caller attr from trait def to impl * relaxing errors * adding tests Approved in a recent lang team meeting: https://github.com/rust-lang/lang-team/blob/master/minutes/2020-01-09.md
-
由 Esteban Küber 提交于
-
由 Esteban Küber 提交于
-
由 bors 提交于
perf(dep_graph): Avoid allocating a set on when the number reads are … …small `reserve_and_rehash` takes up 1.4% of the runtime on the `packed-simd` benchmark which I believe is due to the number of reads are very low in many cases (see https://github.com/rust-lang/rust/pull/50565 for instance). This avoids allocating the set until we start allocating the `reads` `SmallVec` but it is possible that a lower limit might be better (not tested since the improvement will be hard to spot either way).
-
由 Ralf Jung 提交于
-
由 bors 提交于
Allow calculating the layout behind a pointer There was some discussion around allowing this previously. This does make the requirement for raw pointers to have valid metadata exposed as part of the std API (as a safety invariant, not validity invariant), though I think this is not strictly necessarily required as of current. cc @rust-lang/wg-unsafe-code-guidelines Naming is hard; I picked the best "obvious" name I could come up with. If it's agreed that this is actually a desired API surface, I'll file a tracking issue and update the attributes.
-
由 Esteban Küber 提交于
-
由 Esteban Küber 提交于
-
- 22 3月, 2020 12 次提交
-
-
由 bors 提交于
Rollup of 10 pull requests Successful merges: - #68099 (Amend Rc/Arc::from_raw() docs regarding unsafety) - #70172 (parse/lexer: support `StringReader::retokenize` called on external files.) - #70209 (parser: recover on `for<'a> |...| body` closures) - #70223 (fix type of const params in associated types.) - #70229 (more clippy fixes) - #70240 (Return NonZeroU64 from ThreadId::as_u64.) - #70250 (Remove wrong entry from RELEASES.md) - #70253 (Remove another wrong entry from RELEASES.md) - #70254 (couple more clippy fixes (let_and_return, if_same_then_else)) - #70266 (proc_macro_harness: Use item header spans for errors) Failed merges: r? @ghost
-
由 Dylan DPC 提交于
proc_macro_harness: Use item header spans for errors Addresses https://github.com/rust-lang/rust/pull/70233#discussion_r396043004.
-
由 Dylan DPC 提交于
couple more clippy fixes (let_and_return, if_same_then_else) * summarize if-else-code with identical blocks (clippy::if_same_then_else) * don't create variable bindings just to return the bound value immediately (clippy::let_and_return)
-
由 Dylan DPC 提交于
Remove another wrong entry from RELEASES.md The entry is under 1.11.0, but the feature is only available since 1.12.0 (for which an identical entry exists). ![Screenshot_2020-03-22 Support `cfg_attr` on `path` attributes by jseyfried · Pull Request #34546 · rust-lang rust](https://user-images.githubusercontent.com/951129/77238862-85c8f580-6bd4-11ea-8d31-77e2994a4b5a.png)
-
由 Dylan DPC 提交于
Remove wrong entry from RELEASES.md resolves #70247
-
由 Dylan DPC 提交于
Return NonZeroU64 from ThreadId::as_u64. As discussed in #67939, this allows turning Option<ThreadId> into Option<NonZeroU64> which can then be stored inside an AtomicU64.
-
由 Dylan DPC 提交于
more clippy fixes * remove unused unit values (clippy::unused_unit) * make some let-if-bindings more idiomatic (clippy::useless_let_if_seq) * clarify when we pass () to functions (clippy::unit_arg) * don't redundantly repeat field names (clippy::redundant_field_names) * remove redundant returns (clippy::needless_return) * use let instead of match for matches with single bindings (clippy::match_single_binding) * don't convert results to options just for matching (clippy::if_let_some_result)
-
由 Dylan DPC 提交于
parser: recover on `for<'a> |...| body` closures When encountering `for` and `<` is 1 token ahead, interpret this as an explicitly quantified generic closure and recover, rather than attempting to parse a `for` loop. This provides both improved diagnostics as well as an insurance policy for the ability to use this as the syntax for generic closures in the future. As requested by r? @EddyB
-
由 Dylan DPC 提交于
parse/lexer: support `StringReader::retokenize` called on external files. This ~~should theoretically~~ fixes #69933, ~~but I'm not sure what the best way to test it is~~. **EDIT**: see https://github.com/rust-lang/rust/issues/69933#issuecomment-602019598. r? @petrochenkov cc @Xanewok @staktrace
-
由 Dylan DPC 提交于
Amend Rc/Arc::from_raw() docs regarding unsafety [This](https://stackoverflow.com/questions/59671647/is-it-safe-to-clone-a-type-erased-arc-via-raw-pointer) question on SO boils down to "is it safe to `::from_raw()` a `Rc<T>`/`Arc<T>` using a dummy `T` even if `T` is never dereferenced via the new `Rc`/`Arc`?". It almost never is. This PR amends the docs of `from_raw()` regarding this point.
-
由 Guillaume Gomez 提交于
-