bors [Wed, 2 May 2018 02:10:51 +0000 (02:10 +0000)]
Auto merge of #50278 - eddyb:mir-succ-iter, r=nikomatsakis
rustc: return iterators from Terminator(Kind)::successors(_mut).
Minor cleanup (and potentially speedup) prompted by @nnethercote's `SmallVec` experiments.
This PR assumes `.count()` and `.nth(i)` on `iter::Chain<option::IntoIter, slice::Iter(Mut)>` are `O(1)`, but otherwise all of the uses appear to immediately iterate through the successors.
bors [Tue, 1 May 2018 16:58:26 +0000 (16:58 +0000)]
Auto merge of #49789 - petrochenkov:prelext, r=nikomatsakis
Module experiments: Add one more prelude layer for extern crate names passed with `--extern`
Implements one item from https://internals.rust-lang.org/t/the-great-module-adventure-continues/6678/183
When some name is looked up in lexical scope (`name`, i.e. not module-relative scope `some_mod::name` or `::name`), it's searched roughly in the next order:
- local variables
- items in unnamed blocks
- items in the current module
- :sparkles: NEW! :sparkles: crate names passed with `--extern` ("extern prelude")
- standard library prelude (`Vec`, `drop`)
- language prelude (built-in types like `u8`, `str`, etc)
The last two layers contain a limited set of names controlled by us and not arbitrary user-defined names like upper layers. We want to be able to add new names into these two layers without breaking user code, so "extern prelude" names have higher priority than std prelude and built-in types.
This is a one-time breaking change, that's why it would be nice to run this through crater.
Practical impact is expected to be minimal though due to stylistic reasons (there are not many `Uppercase` crates) and due to the way how primitive types are resolved (https://github.com/rust-lang/rust/pull/32131).
This reworks the force-frame-pointer PR to explicitly only consider the
value of the flag if it is provided, and use a target default otherwise.
Something that was tried but not kept was renaming the flag to
`frame-pointer`, because for flag `frame-pointer=no`, there is no
guarante, that LLVM will elide *all* the frame pointers; oposite of what
the literal reading of the flag would suggest.
Don't force-enable frame pointers when generating debug info
We apparently used to generate bad/incomplete debug info causing
debuggers not to find symbols of stack allocated variables. This was
somehow worked around by having frame pointers.
With the current codegen, this seems no longer necessary, so we can
remove the code that force-enables frame pointers whenever debug info
is requested.
Since certain situations, like profiling code profit from having frame
pointers, we add a -Cforce-frame-pointers flag to always enable frame
pointers.
bors [Tue, 1 May 2018 00:16:16 +0000 (00:16 +0000)]
Auto merge of #50197 - nikomatsakis:skolemize-out-of-tcx, r=eddyb
move skolemized regions into global tcx
Experimental branch to move skolemized regions into global tcx. This is probably not what we want long term but may be convenient to unblock @sgrif in the short term.
I'd like to do a perf run, though the main concern I guess would be memory usage.
- #50233 (Make `Vec::new` a `const fn`)
- #50312 (Add more links in panic docs)
- #50316 (Fix some broken links in docs.)
- #50325 (Add a few more tests for proc macro feature gating)
- #50327 (Display correct unused field suggestion for nested struct patterns)
- #50330 (check that #[used] is used only on statics)
- #50344 (Update Cargo to 2018-04-28 122fd5be5201913d42e219e132d6569493583bca)
Rollup merge of #50233 - mark-i-m:const_vec, r=kennytm
Make `Vec::new` a `const fn`
`RawVec::empty/_in` are a hack. They're there because `if size_of::<T> == 0 { !0 } else { 0 }` is not allowed in `const` yet. However, because `RawVec` is unstable, the `empty/empty_in` constructors can be removed when #49146 is done...
Auto merge of #50092 - abonander:issue-49934, r=petrochenkov
Warn on pointless #[derive] in more places
This fixes the regression in #49934 and ensures that unused `#[derive]` invocations on statements, expressions and generic type parameters survive to trip the `unused_attributes` lint. There is a separate warning hardcoded for `#[derive]` on macro invocations since linting (even the early-lint pass) occurs after expansion. This also adds regression tests for some nodes that were already warning properly.
This fixes the regression in #49934 and ensures that unused `#[derive]`s on statements, expressions and generic type parameters survive to trip the `unused_attributes` lint. For `#[derive]` on macro invocations it has a hardcoded warning since linting occurs after expansion. This also adds regression testing for some nodes that were already warning properly.
Auto merge of #50300 - phansch:update_clippy, r=oli-obk
Update clippy
First time doing this. Not sure if this is enough as the docs mention that the Cargo.lock should be updated, however running `cargo update -p clippy` and `./x.py` doesn't change anything.
Zack M. Davis [Sat, 10 Mar 2018 22:26:33 +0000 (14:26 -0800)]
in which the fn-must-use codepath is prevented from panicking on closure
The must-use lint needs the DefId of called functions and method
receivers in order to look for a `#[must_use]` attribute, but this would
ICE (!) if a called function was actually a closure (with a non-unit
return value). Instead, let's be specific that we want a `Def::Fn`,
rather than blithely assuming that we can get the DefId of a qpath.
Supporting must-use closures doesn't seem like a priority, but could
conceivably be added in the future if desired (conditional on the
statement and expression attributes (#15701) story being amicable).
* ~~fbf6423 The tail type was not normalized.~~
* https://github.com/rust-lang/rust/commit/d0839d5680d2a51785eeb0811cf3e2beba90eacb The method had a wrong assumption that something whose parent is a trait is an associated item. Fixes #48984.
Auto merge of #50188 - alexcrichton:feature-all-the-things, r=eddyb
Add `-C target-feature` to all functions
Previously the features specified to LLVM via `-C target-feature` were only
reflected in the `TargetMachine` but this change *also* reflects these and the
base features inside each function itself. This change matches clang and...
Alex Crichton [Mon, 23 Apr 2018 22:17:07 +0000 (15:17 -0700)]
Add `-C target-feature` to all functions
Previously the features specified to LLVM via `-C target-feature` were only
reflected in the `TargetMachine` but this change *also* reflects these and the
base features inside each function itself. This change matches clang and...
Auto merge of #50240 - nnethercote:LazyBTreeMap, r=cramertj
Implement LazyBTreeMap and use it in a few places.
This is a thin wrapper around BTreeMap that avoids allocating upon creation.
I would prefer to change BTreeMap directly to make it lazy (like I did with HashSet in #36734) and I initially attempted that by making BTreeMap::root an Option<>. But then I also had to change Iter and Range to handle trees with no root, and those types have stability markers on them and I wasn't sure if that was acceptable. Also, BTreeMap has a lot of complex code and changing it all was challenging, and I didn't have high confidence about my general approach.
So I prototyped this wrapper instead and used it in the hottest locations to get some measurements about the effect. The measurements are pretty good!
- Doing a debug build of serde, it reduces the total number of heap allocations from 17,728,709 to 13,359,384, a 25% reduction. The number of bytes allocated drops from 7,474,672,966 to 5,482,308,388, a 27% reduction.
- It gives speedups of up to 3.6% on some rustc-perf benchmark jobs. crates.io, futures, and serde benefit most.
```
futures-check
avg: -1.9% min: -3.6% max: -0.5%
serde-check
avg: -2.1% min: -3.5% max: -0.7%
crates.io-check
avg: -1.7% min: -3.5% max: -0.3%
serde
avg: -2.0% min: -3.0% max: -0.9%
serde-opt
avg: -1.8% min: -2.9% max: -0.3%
futures
avg: -1.5% min: -2.8% max: -0.4%
tokio-webpush-simple-check
avg: -1.1% min: -2.2% max: -0.1%
futures-opt
avg: -1.2% min: -2.1% max: -0.4%
piston-image-check
avg: -0.8% min: -1.1% max: -0.3%
crates.io
avg: -0.6% min: -1.0% max: -0.3%
```
@Gankro, how do you think I should proceed here? Is leaving this as a wrapper reasonable? Or should I try to make BTreeMap itself lazy? If so, can I change the representation of Iter and Range?
projects / rust.git / log