bors [Tue, 19 May 2020 15:12:12 +0000 (15:12 +0000)]
Auto merge of #72227 - nnethercote:tiny-vecs-are-dumb, r=Amanieu
Tiny Vecs are dumb.
Currently, if you repeatedly push to an empty vector, the capacity
growth sequence is 0, 1, 2, 4, 8, 16, etc. This commit changes the
relevant code (the "amortized" growth strategy) to skip 1 and 2, instead
using 0, 4, 8, 16, etc. (You can still get a capacity of 1 or 2 using
the "exact" growth strategy, e.g. via `reserve_exact()`.)
This idea (along with the phrase "tiny Vecs are dumb") comes from the
"doubling" growth strategy that was removed from `RawVec` in #72013.
That strategy was barely ever used -- only when a `VecDeque` was grown,
oddly enough -- which is why it was removed in #72013.
(Fun fact: until just a few days ago, I thought the "doubling" strategy
was used for repeated push case. In other words, this commit makes
`Vec`s behave the way I always thought they behaved.)
This change reduces the number of allocations done by rustc itself by
10% or more. It speeds up rustc, and will also speed up any other Rust
program that uses `Vec`s a lot.
In theory, the change could increase memory usage, but in practice it
doesn't. It would be an unusual program where very small `Vec`s having a
capacity of 4 rather than 1 or 2 would make a difference. You'd need a
*lot* of very small `Vec`s, and/or some very small `Vec`s with very
large elements.
Dylan DPC [Tue, 19 May 2020 11:53:43 +0000 (13:53 +0200)]
Rollup merge of #72068 - estebank:mut-deref-hack, r=oli-obk
Ignore arguments when looking for `IndexMut` for subsequent `mut` obligation
Given code like `v[&field].boo();` where `field: String` and
`.boo(&mut self)`, typeck will have decided that `v` is accessed using
`Index`, but when `boo` adds a new `mut` obligation,
`convert_place_op_to_mutable` is called. When this happens, for *some
reason* the arguments' dereference adjustments are completely ignored
causing an error saying that `IndexMut` is not satisfied:
```
error[E0596]: cannot borrow data in an index of `Indexable` as mutable
--> src/main.rs:30:5
|
30 | v[&field].boo();
| ^^^^^^^^^ cannot borrow as mutable
|
= help: trait `IndexMut` is required to modify indexed content, but it is not implemented for `Indexable`
```
This is not true, but by changing `try_overloaded_place_op` to retry
when given `Needs::MutPlace` without passing the argument types, the
example successfully compiles.
I believe there might be more appropriate ways to deal with this.
bors [Tue, 19 May 2020 08:08:48 +0000 (08:08 +0000)]
Auto merge of #71447 - cuviper:unsized_cow, r=dtolnay
impl From<Cow> for Box, Rc, and Arc
These forward `Borrowed`/`Owned` values to existing `From` impls.
- `Box<T>` is a fundamental type, so it would be a breaking change to add a blanket impl. Therefore, `From<Cow>` is only implemented for `[T]`, `str`, `CStr`, `OsStr`, and `Path`.
- For `Rc<T>` and `Arc<T>`, `From<Cow>` is implemented for everything that implements `From` the borrowed and owned types separately.
Dylan DPC [Mon, 18 May 2020 17:04:03 +0000 (19:04 +0200)]
Rollup merge of #71973 - lcnr:lazy-norm, r=nikomatsakis
Lazy normalization of constants (Reprise)
Continuation of #67890 by @skinny121.
Initial implementation of #60471 for constants.
Perform normalization/evaluation of constants lazily, which is known as lazy normalization. Lazy normalization is only enabled when using `#![feature(lazy_normalization_consts)]`, by default constants are still evaluated eagerly as there are currently.
Lazy normalization of constants is achieved with a new ConstEquate predicate which type inferences uses to delay checking whether constants are equal to each other until later, avoiding cycle errors.
Note this doesn't allow the use of generics within repeat count expressions as that is still evaluated during conversion to mir. There are also quite a few other known problems with lazy normalization which will be fixed in future PRs.
Dylan DPC [Mon, 18 May 2020 17:04:01 +0000 (19:04 +0200)]
Rollup merge of #71599 - ldm0:fnclo, r=nikomatsakis
Support coercion between (FnDef | Closure) and (FnDef | Closure)
Fixes #46742, fixes #48109
Inject `Closure` into the `FnDef x FnDef` coercion special case, which makes coercion of `(FnDef | Closure) x (FnDef | Closure)` possible, where closures should be **non-capturing**.
bors [Mon, 18 May 2020 11:11:19 +0000 (11:11 +0000)]
Auto merge of #72289 - RalfJung:abort_internal, r=Mark-Simulacrum
abort_internal is safe
`sys::abort_internal` is stably exposed as a safe function. Forward that assumption "inwards" to the `sys` module by making the function itself safe, too.
This corresponds to what https://github.com/rust-lang/rust/pull/72204 did for the intrinsic. We should probably wait until that lands because some of the intrinsic calls in this PR might then need adjustments.
Ralf Jung [Mon, 18 May 2020 06:48:43 +0000 (08:48 +0200)]
Rollup merge of #72143 - rust-lang:steveklabnik-must-use, r=sfackler
make offset must_use
https://djugei.github.io/bad-at-unsafe/ describes an error a user had when trying to use offset:
> At first I just assumed that the .add() and .offset() methods on pointers would mutate the pointer. They do not. Instead they return a new pointer, which gets dropped silently if you don't use it. Unlike for example Result, which is must_use annotated.
This PR only adds `offset`, because I wanted to float the idea; I'm imagining that there's more than just `add` and `offset` that could use this. I am also very open to re-wording the warning.
Currently, if you repeatedly push to an empty vector, the capacity
growth sequence is 0, 1, 2, 4, 8, 16, etc. This commit changes the
relevant code (the "amortized" growth strategy) to skip 1 and 2 in most
cases, instead using 0, 4, 8, 16, etc. (You can still get a capacity of
1 or 2 using the "exact" growth strategy, e.g. via `reserve_exact()`.)
This idea (along with the phrase "tiny Vecs are dumb") comes from the
"doubling" growth strategy that was removed from `RawVec` in #72013.
That strategy was barely ever used -- only when a `VecDeque` was grown,
oddly enough -- which is why it was removed in #72013.
(Fun fact: until just a few days ago, I thought the "doubling" strategy
was used for repeated push case. In other words, this commit makes
`Vec`s behave the way I always thought they behaved.)
This change reduces the number of allocations done by rustc itself by
10% or more. It speeds up rustc, and will also speed up any other Rust
program that uses `Vec`s a lot.
bors [Sun, 17 May 2020 16:20:19 +0000 (16:20 +0000)]
Auto merge of #72295 - RalfJung:rollup-icmhbs7, r=RalfJung
Rollup of 3 pull requests
Successful merges:
- #72259 (Disallow forbidden usage of non-ascii identifiers.)
- #72261 (Break out early on empty span when generate_fn_span)
- #72291 (bootstrap: fix typo)
Steve Klabnik [Tue, 12 May 2020 16:41:41 +0000 (11:41 -0500)]
make many ptr functions must_use
https://djugei.github.io/bad-at-unsafe/ describes an error a user had when trying to use offset:
> At first I just assumed that the .add() and .offset() methods on pointers would mutate the pointer. They do not. Instead they return a new pointer, which gets dropped silently if you don't use it. Unlike for example Result, which is must_use annotated.
bors [Sun, 17 May 2020 12:49:01 +0000 (12:49 +0000)]
Auto merge of #72204 - RalfJung:abort, r=Mark-Simulacrum
make abort intrinsic safe, and correct its documentation
Turns out `std::process::abort` is not the same as the intrinsic, the comment was just wrong. Quoting from the unix implementation:
```
// On Unix-like platforms, libc::abort will unregister signal handlers
// including the SIGABRT handler, preventing the abort from being blocked, and
// fclose streams, with the side effect of flushing them so libc buffered
// output will be printed. Additionally the shell will generally print a more
// understandable error message like "Abort trap" rather than "Illegal
// instruction" that intrinsics::abort would cause, as intrinsics::abort is
// implemented as an illegal instruction.
```
Ben Lewis [Thu, 2 Jan 2020 02:41:34 +0000 (15:41 +1300)]
Emit `ConstEquate` obligation after checking/unifying for inference variables. This means
a inference variable can be unified with an unevaluated const.
Ben Lewis [Fri, 28 Feb 2020 21:03:04 +0000 (10:03 +1300)]
Assume unevaluated consts are equal to the other consts and add ConstEquate obligation. This delays
the need to evaluate consts eagerly and therefore gets around const eval query cycles.
bors [Sun, 17 May 2020 05:41:39 +0000 (05:41 +0000)]
Auto merge of #5608 - flip1995:rustup, r=phansch
Rustup with git subtree
The commits from the last rustup #5587, are again included in this rustup, since I rebased the rustup. Lesson learned: never rebase, only merge when working with git subtree.
bors [Sun, 17 May 2020 01:31:15 +0000 (01:31 +0000)]
Auto merge of #72286 - Dylan-DPC:rollup-n3rk6df, r=Dylan-DPC
Rollup of 4 pull requests
Successful merges:
- #72233 (Fix {:#?} representation of proc_macro::Literal)
- #72277 (emphasize that ManuallyDrop is safe-to-access and unsafe-to-drop)
- #72281 (Fix whitespace in `?Sized` structured suggestion)
- #72282 (Fix issue number typo in note)
bors [Sat, 16 May 2020 22:16:48 +0000 (22:16 +0000)]
Auto merge of #72178 - tmiasko:inliner-lifetimes, r=nikic
Consistently use LLVM lifetime markers during codegen
Ensure that inliner inserts lifetime markers if they have been emitted during
codegen. Otherwise if allocas from inlined functions are merged together,
lifetime markers from one function might invalidate load & stores performed
by the other one.
bors [Sat, 16 May 2020 20:17:11 +0000 (20:17 +0000)]
Auto merge of #5563 - ThibsG:MergeLints, r=flip1995
Merge some lints together
This PR merges following lints:
- `block_in_if_condition_expr` and `block_in_if_condition_stmt` → `blocks_in_if_conditions`
- `option_map_unwrap_or`, `option_map_unwrap_or_else` and `result_map_unwrap_or_else` → `map_unwrap`
- `option_unwrap_used` and `result_unwrap_used` → `unwrap_used`
- `option_expect_used` and `result_expect_used` → `expect_used`
- `wrong_pub_self_convention` into `wrong_self_convention`
- `for_loop_over_option` and `for_loop_over_result` → `for_loops_over_fallibles`
Lints that have already been merged since the issue was created:
- [x] `new_without_default` and `new_without_default_derive` → `new_without_default`
Need more discussion:
- `string_add` and `string_add_assign`: do we agree to merge them or not? Is there something more to do? → **not merge finally**
- `identity_op` and `modulo_one` → `useless_arithmetic`: seems outdated, since `modulo_arithmetic` has been created.
fixes #1078
changelog: Merging some lints together:
- `block_in_if_condition_expr` and `block_in_if_condition_stmt` → `blocks_in_if_conditions`
- `option_map_unwrap_or`, `option_map_unwrap_or_else` and `result_map_unwrap_or_else` → `map_unwrap_or`
- `option_unwrap_used` and `result_unwrap_used` → `unwrap_used`
- `option_expect_used` and `result_expect_used` → `expect_used`
- `for_loop_over_option` and `for_loop_over_result` → `for_loops_over_fallibles`
bors [Sat, 16 May 2020 17:47:21 +0000 (17:47 +0000)]
Auto merge of #72276 - RalfJung:rollup-nkfu3is, r=RalfJung
Rollup of 5 pull requests
Successful merges:
- #72045 (Incomplete features can also be unsound)
- #72047 (Literal error reporting cleanup)
- #72060 (move `ty::List` into a new submodule)
- #72094 (cmdline: Make target features individually overridable)
- #72254 (Remove redundant backtick in error message.)
Previously `-C target-feature=+avx2 -C target-feature=+fma` was equivalent to `-C target-feature=+fma` because the later `-C target-feature` option fully overridden previous `-C target-feature`.
With this PR `-C target-feature=+avx2 -C target-feature=+fma` is equivalent to `-C target-feature=+avx2,+fma` and the options are combined.
I'm not sure where the comma-separated features in a single option came from (clang uses a scheme with single feature per-option), but logically these features are entirely independent options.
So they should be overridable individually as well to be more useful in hierarchical build system, and more consistent with other rustc options and clang behavior as well.
Target feature options have a few other issues (https://github.com/rust-lang/rust/issues/44815), but fixing those is going to be a bit more invasive.
Ralf Jung [Sat, 16 May 2020 17:46:31 +0000 (19:46 +0200)]
Rollup merge of #72047 - Julian-Wollersberger:literal_error_reporting_cleanup, r=petrochenkov
Literal error reporting cleanup
While doing some performance work, I noticed some code duplication in `librustc_parser/lexer/mod.rs`, so I cleaned it up.
This PR is probably best reviewed commit by commit.
I'm not sure what the API stability practices for `librustc_lexer` are. Four public methods in `unescape.rs` can be removed, but two are used by clippy, so I left them in for now.
I could open a PR for Rust-Analyzer when this one lands.
But how do I open a PR for clippy? (Git submodules are frustrating to work with)
Ralf Jung [Sat, 16 May 2020 17:46:31 +0000 (19:46 +0200)]
Rollup merge of #72047 - Julian-Wollersberger:literal_error_reporting_cleanup, r=petrochenkov
Literal error reporting cleanup
While doing some performance work, I noticed some code duplication in `librustc_parser/lexer/mod.rs`, so I cleaned it up.
This PR is probably best reviewed commit by commit.
I'm not sure what the API stability practices for `librustc_lexer` are. Four public methods in `unescape.rs` can be removed, but two are used by clippy, so I left them in for now.
I could open a PR for Rust-Analyzer when this one lands.
But how do I open a PR for clippy? (Git submodules are frustrating to work with)
Ralf Jung [Sat, 16 May 2020 17:46:29 +0000 (19:46 +0200)]
Rollup merge of #72045 - RalfJung:incomplete-unsound, r=petrochenkov
Incomplete features can also be unsound
Some incomplete features do not just ICE, they are also currently unsound (e.g. https://github.com/rust-lang/rust/pull/72029, and also `specialization` -- which is not yet marked incomplete but [should be](https://github.com/rust-lang/rust/pull/71420)). This makes the message reflect that.
While at it I also added a link to the tracking issue, which hopefully should explain what is incomplete/unsound about the feature.
bors [Sat, 16 May 2020 14:15:18 +0000 (14:15 +0000)]
Auto merge of #72262 - Dylan-DPC:rollup-x56q1jj, r=Dylan-DPC
Rollup of 7 pull requests
Successful merges:
- #71625 (Improve the documentation for ManuallyDrop to resolve conflicting usage of terminology)
- #71919 (Update transitive dependency to work towards removing syn <1.0 dep)
- #72166 (Simpler slice `Iterator` methods)
- #72216 (Remove `lang_items\(\).*\.unwrap\(\)`)
- #72230 (Updated documentation of Prefix::VerbatimDisk)
- #72234 (Implement Default for proc_macro::TokenStream)
- #72258 (Fix typo Arbintrary to Arbitrary)
Dylan DPC [Sat, 16 May 2020 10:43:05 +0000 (12:43 +0200)]
Rollup merge of #72230 - SOF3:patch-1, r=kennytm
Updated documentation of Prefix::VerbatimDisk
PrefixComponent with Prefix::VerbatimDisk does not contain the trailing slash. The documentation here is also inconsistent with the documentation on other variants that reflect the `PrefixComponent::as_os_str()` return value.
Dylan DPC [Sat, 16 May 2020 10:42:59 +0000 (12:42 +0200)]
Rollup merge of #71919 - Xanewok:bump-syn-1, r=Xanewok
Update transitive dependency to work towards removing syn <1.0 dep
This bumps a couple of transitive dependencies in hopes of eventually not transitively depending on syn <1.0 and friends. The only upstream changes that this is blocked on seems to be https://github.com/mattico/elasticlunr-rs/pull/27 and https://github.com/rust-lang/mdBook/pull/1210.
While working on https://github.com/rust-lang/rust/pull/71875 I noticed we still use syn 0.15 here and there so this is a drive-by PR which aims to help with things a bit.