Alex Crichton [Fri, 15 Sep 2017 04:28:55 +0000 (21:28 -0700)]
rustc: Preallocate when building the dep graph
This commit alters the `query` function in the dep graph module to preallocate
memory using `with_capacity` instead of relying on automatic growth. Discovered
in #44576 it was found that for the syntex_syntax clean incremental benchmark
the peak memory usage was found when the dep graph was being saved, particularly
the `DepGraphQuery` data structure itself. PRs like #44142 which add more
queries end up just making this much larger!
I didn't see an immediately obvious way to reduce the size of the
`DepGraphQuery` object, but it turns out that `with_capacity` helps quite a bit!
Locally 831 MB was used [before] this commit, and 770 MB is in use at the peak
of the compiler [after] this commit. That's a nice 7.5% improvement! This won't
quite make up for the losses in #44142 but I figured it's a good start.
Auto merge of #44502 - alexcrichton:remove-session-dep-graph, r=michaelwoerister
rustc: Remove `Session::dep_graph`
This commit removes the `dep_graph` field from the `Session` type according to
issue #44390. Most of the fallout here was relatively straightforward and the
`prepare_session_directory` function was rejiggered a bit to reuse the results
in the later-called `load_dep_graph` function.
Alex Crichton [Sat, 9 Sep 2017 18:02:18 +0000 (11:02 -0700)]
rustc: Remove `Session::dep_graph`
This commit removes the `dep_graph` field from the `Session` type according to
issue #44390. Most of the fallout here was relatively straightforward and the
`prepare_session_directory` function was rejiggered a bit to reuse the results
in the later-called `load_dep_graph` function.
Auto merge of #44480 - Zoxc:gen-liveness, r=arielb1
Analyse storage liveness and preserve it during generator transformation
This uses a dataflow analysis on `StorageLive` and `StorageDead` statements to infer where the storage of locals are live. The result of this analysis is intersected with the regular liveness analysis such that a local is can only be live when its storage is. This fixes https://github.com/rust-lang/rust/issues/44184. If the storage of a local is live across a suspension point, we'll insert a `StorageLive` statement for it after the suspension point so storage liveness is preserved. This fixes https://github.com/rust-lang/rust/issues/44179.
Auto merge of #44526 - leodasvacas:remove-deprecated-lang-items, r=arielb1
Remove deprecated lang items
They have been deprecated for years and there is no trace left of them in the compiler. Also removed `require_owned_box` which is dead code and other small refactorings.
In many aspects implementations for linux also apply for the L4Re microkernel.
Some uncommon characteristics had to be resolved:
* L4Re has no network funktionality
* L4Re has a maximum stacksize of 1Mb for threads
* L4Re has no uid or gid
Co-authored-by: Sebastian Humenda <sebastian.humenda@tu-dresden.de>
Auto merge of #44516 - gaurikholkar:fns, r=arielb1
Extend E0623 for fn items
This fixes #44516
The below example now gives
```
error[E0623]: lifetime mismatch
--> gg.rs:3:10
|
2 | fn foo(x:fn(&u8, &u8), y: Vec<&u8>, z: &u8) {
| --- --- these two types are declared with different lifetimes...
3 | y.push(z);
| ^ ...but data from `z` flows into `y` here
Fix issue #43481: emit the EndRegion *before* StorageDeads for a scope.
(The idea is that the StorageDead marks the point where the memory can
be deallocated, and the EndRegion is marking where borrows of that
memory can no longer legally exist.)
Most of the Rust community uses 4 spaces for indentation,
but there are also tab users of Rust (including myself!).
This patch fixes a bug in error printing which mispositions
error indicators when near code with tabs.
The code attempted to fix the issue by replacing spaces
with tabs, but it sadly wasn't enough, as sometimes
you may not print spaces but _ or ^ instead.
This patch employs the reverse strategy: it replaces each
tab with a space, so that the number of _ and ^ and spaces
in error indicators below the code snippet line up
perfectly.
In a study [1] preceeding this patch, we could see that
this strategy is also chosen by gcc version 6.3.0.
Its not perfect, as the output is not beautiful, but its
the easiest to implement. If anyone wants to improve on
this, be my guest! This patch is meant as improvement of
the status quo, not as perfect end status. It fixes the
actual issue of mispositioning error indicators.
Auto merge of #44015 - kennytm:hasher, r=alexcrichton
impl Hasher for {&mut Hasher, Box<Hasher>}
**Rationale:** The `Hash` trait has `fn hash<H: Hasher>(&self, state: &mut H)`, which can only accept a `Sized` hasher, even if the `Hasher` trait is object-safe. We cannot retroactively add the `?Sized` bound without breaking stability, thus implementing `Hasher` to a trait object reference is the next best solution.
**Warning:** These `impl` are insta-stable, and should need an FCP. I don't think a full RFC is necessary.
Auto merge of #44133 - vorner:allocator-kind-autodetect, r=alexcrichton
Autodetect the type of allocator crate used
Annotate the allocator crates (allocator_system, allocator_jemalloc) by the type of allocator they are. If one is requested as an exe allocator, detect its type by the flags.
This has the effect that using this (de jure wrong) configuration in the target spec works instead of producing a really unhelpful and arcane linker error:
"exe-allocation-crate": "alloc_system"
Fixes #43524.
There are two yet unsolved FIXME's, I'll be glad for some advice on what to do with them.
Auto merge of #44344 - jonhoo:entry_or_default, r=BurntSushi
Add or_default to Entry APIs
As argued for in #44324, this PR adds a new `or_default` method to the various `Entry` APIs (currently just for `BTreeMap` and `HashMap`) when `V: Default`. This method is effectively a shorthand for `or_insert_with(Default::default)`.
Auto merge of #44310 - ldr709:master, r=BurntSushi
Additional traits for std::mem::ManuallyDrop
The first commit adds `Clone` and `Copy` trait implementations for `ManuallyDrop`. Although `Drop` and `Copy` cannot be used together, this may be useful for generics.
The second commit adds implementations common traits. I do not think this is necessary, as they could be implemented in a wrapper type outside the standard library, but it would make `ManuallyDrop` more convenient to use.
This is in preparation for polymorphic array lengths (aka `[T; T::A]`) and const generics.
We need deferred const-evaluation to break cycles when array types show up in positions which require knowing the array type to typeck the array length, e.g. the array type is in a `where` clause.
The final step - actually passing bounds in scope to array length expressions from the parent - is not done because it still produces cycles when *normalizing* `ParamEnv`s, and @nikomatsakis' in-progress lazy normalization work is needed to deal with that uniformly.
However, the changes here are still useful to unlock work on const generics, which @EpicatSupercell manifested interest in, and I might be mentoring them for that, but we need this baseline first.
Auto merge of #44442 - Aaron1011:promote-static-ref, r=eddyb
Fix regression in promotion of rvalues referencing a static
This commit makes librustc_passes::consts::CheckCrateVisitor properly
mark expressions as promotable if they reference a static, as it's
perfectly fine for one static to reference another. It fixes a
regression that prevented a temporary rvalue from referencing a static
if it was itself declared within a static.
Prior to commit https://github.com/rust-lang/rust/commit/b8c05fe90bc,
`region::ScopeTree` would only register a 'terminating scope' for function
bodies. Thus, while rvalues in a static that referenced a static would be marked
unpromotable, the lack of enclosing scope would cause
mem_categorization::MemCategorizationContext::cat_rvalue_node
to compute a 'temporary scope' of `ReStatic`. Since this had the same
effect as explicitly selecting a scope of `ReStatic`
due to the rvalue being marked by CheckCrateVisitor as promotable,
no issue occurred.
However, commit https://github.com/rust-lang/rust/commit/b8c05fe90bc
made ScopeTree unconditionally register a 'terminating scope'
Since mem_categorization would now compute a non-static 'temporary scope', the
aforementioned rvalues would be erroneously marked as living for too
short a time.
By fixing the behavior of CheckCrateVisitor, this commit avoids changing
mem_categorization's behavior, while ensuring that temporary values in
statics are still allowed to reference other statics.
Alex Crichton [Fri, 8 Sep 2017 20:51:57 +0000 (13:51 -0700)]
rustc: Remove HirId from queries
This'll allow us to reconstruct query parameters purely from the `DepNode`
they're associated with. Some queries could move straight to `HirId` but others
that don't always have a correspondance between `HirId` and `DefId` moved to
two-level maps where the query operates over a `DefIndex`, returning a map,
which is then keyed off `ItemLocalId`.
Auto merge of #44440 - cuviper:min_global_align, r=japaric
Add `TargetOptions::min_global_align`, with s390x at 16-bit
The SystemZ `LALR` instruction provides PC-relative addressing for globals,
but only to *even* addresses, so other compilers make sure that such
globals are always 2-byte aligned. In Clang, this is modeled with
`TargetInfo::MinGlobalAlign`, and `TargetOptions::min_global_align` now
serves the same purpose for rustc.
In Clang, the only targets that set this are SystemZ, Lanai, and NVPTX, and
the latter two don't have targets in rust master.
Auto merge of #44410 - alexcrichton:fix-travis, r=Mark-Simulacrum
Fix sanitizer tests on buggy kernels
Travis recently pushed an update to the Linux environments, namely the kernels
that we're running on. This in turn caused some of the sanitizer tests we run to
fail. We also apparently weren't the first to hit these failures! Detailed in
google/sanitizers#837 these tests were failing due to a specific commit in the
kernel which has since been backed out, but for now work around the buggy kernel
that's deployed on Travis and eventually we should be able to remove these
flags.
Auto merge of #44220 - kennytm:fix-44216-instance-plus-max-duration-should-panic, r=alexcrichton
Properly detect overflow in Instance ± Duration.
Fix #44216.
Fix #42622
The computation `Instant::now() + Duration::from_secs(u64::max_value())` now panics. The call `receiver.recv_timeout(Duration::from_secs(u64::max_value()))`, which involves such time addition, will also panic.
The reason #44216 arises is because of an unchecked cast from `u64` to `i64`, making the duration equivalent to -1 second.
Note that the current implementation is over-conservative, since e.g. (-2⁶²) + (2⁶³) is perfectly fine for an `i64`, yet this is rejected because (2⁶³) overflows the `i64`.
Annotate the allocator crates (allocator_system, allocator_jemalloc) by
the type of allocator they are. If one is requested as an exe allocator,
detect its type by the flags.
This has the effect that using this (de jure wrong) configuration in the
target spec works instead of producing a really unhelpful and arcane
linker error:
Auto merge of #44079 - gaurikholkar:named_conf, r=nikomatsakis
Extend E0623 for LateBound and EarlyBound Regions
This is a fix for #43882
```
fn foo<'a,'b>(x: &mut Vec<&'a u8>, y: &'b u8) {
x.push(y);
}
```
now gives
```
error[E0623]: lifetime mismatch
--> $DIR/ex3-both-anon-regions-latebound-regions.rs:12:12
|
11 | fn foo<'a,'b>(x: &mut Vec<&'a u8>, y: &'b u8) {
| ------ ------ these two types are declared with different lifetimes...
12 | x.push(y);
| ^ ...but data from `y` flows into `x` here
```
cc @nikomatsakis @arielb1
Please ignore the second commit. It will be merged in a separate PR.
Rollup merge of #44372 - bgermann:master, r=alexcrichton
Use memalign instead of posix_memalign for Solaris
As pointed out in https://github.com/rust-lang/libc/commit/deb61c8,
Solaris 10 does not support posix_memalign.
Use memalign for all Solaris versions instead.
With this change applied I am able to cross-build rustc for Solaris 10.
Rollup merge of #44332 - tirr-c:issue-44021, r=petrochenkov
Expect pipe symbol after closure parameter list
Fixes #44021.
---
Originally, the parser just called `bump` to discard following token after parsing closure parameter list, because it assumes `|` is following. However, the following code breaks the assumption:
Rollup merge of #44262 - alexcrichton:repr-128-gate, r=nikomatsakis
rustc: Separately feature gate repr(i128)
Brought up during the discussion of #35118, the support for this is still
somewhat buggy and so stabilization likely wants to be considered independently
of the type itself.
Auto merge of #44312 - eddyb:static-by-any-other-name, r=alexcrichton
Use rvalue promotion to 'static instead of static items.
Fixes #44240. Among other things, in crates that do a lot of formatting, this could reduce the number of items, although I haven't measured the performance benefits. If there's a codegen slowdown, that should IMO be solved by caching the output of miri, *not* by using `static`.
Auto merge of #44260 - alexcrichton:hardlink-no-copy, r=Mark-Simulacrum
rustbuild: Switch back to using hard links
The `copy` function historically in rustbuild used hard links to speed up the
copy operations that it does. This logic was backed out, however, in #39518 due
to a bug that only showed up on Windows, described in #39504. The cause
described in #39504 happened because Cargo, on a fresh build, would overwrite
the previous artifacts with new hard links that Cargo itself manages.
This behavior in Cargo was fixed in rust-lang/cargo#4390 where it no longer
should overwrite files on fresh builds, opportunistically leaving the filesystem
intact and not touching it.
Hopefully this can help speed up local builds by doing fewer copies all over the
place!
Alex Crichton [Sat, 2 Sep 2017 03:46:51 +0000 (20:46 -0700)]
rustbuild: Switch back to using hard links
The `copy` function historically in rustbuild used hard links to speed up the
copy operations that it does. This logic was backed out, however, in #39518 due
to a bug that only showed up on Windows, described in #39504. The cause
described in #39504 happened because Cargo, on a fresh build, would overwrite
the previous artifacts with new hard links that Cargo itself manages.
This behavior in Cargo was fixed in rust-lang/cargo#4390 where it no longer
should overwrite files on fresh builds, opportunistically leaving the filesystem
intact and not touching it.
Hopefully this can help speed up local builds by doing fewer copies all over the
place!
Auto merge of #44251 - kennytm:osx-backtrace, r=alexcrichton
Add libbacktrace support for Apple platforms (resubmitted)
Resubmitting #43422 rebased on the current master (cc @JohnColanduoni).
I have added an additional commit to fallback to `dladdr`-based `resolve_symbol` if `libbacktrace` returns `None`, otherwise the stack trace will be full of `<unknown>` when you forget to pass the `-g` flag (actually it seems — at least on macOS — the `dladdr` symbol is more accurate than the `libbacktrace` one).
Auto merge of #44438 - Xaeroxe:clamp, r=Mark-Simulacrum
Revert clamp
Revert clamp per https://github.com/rust-lang/rust/issues/44095#issuecomment-328218316 while we take time to assess the potential backwards compatibility damage done by it.
projects / rust.git / log