This code is assuming that usize >= 32bits, but it is not the case on
16bit targets. It is producing a warning that will fail the compilation
on MSP430 if deny(warnings) is enabled.
It is very unlikely that someone would actually use this code on
a microcontroller, but since unicode was merged into libcore we
have compile it on 16bit targets.
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.
r? @eddyb
Rollup of 7 pull requests
Successful merges:
- #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)
Failed merges:
check that #[used] is used only on statics
this attribute has no effect on other items. This makes the implementation match what's described in the RFC.
cc #40289
r? @nagisa
Add more links in panic docs
Fixes#48695 by adding a link to `AssertUnwindSafe`. Also added some other links in the module's docs to make things clearer.
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...
Bury Error::description()
Second attempt of #49536https://github.com/rust-lang/rfcs/pull/2230
The exact wording of the default implementation is still up in the air, but I think it's a detail that can be amended later.
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.
closes#49934
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.
closes#49934
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.
Closes https://github.com/rust-lang-nursery/rust-clippy/issues/2700
r? @oli-obk
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).
Fix ICE #48984
* ~~fbf6423 The tail type was not normalized.~~
* d0839d5680 The method had a wrong assumption that something whose parent is a trait is an associated item. Fixes#48984.
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...
Closesrust-lang-nursery/stdsimd#427
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...
Closesrust-lang-nursery/stdsimd#427
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?
Thanks!
