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.
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.
bors [Sat, 16 May 2020 10:32:46 +0000 (10:32 +0000)]
Auto merge of #71872 - nnethercote:less-aggressive-arena-growth, r=oli-obk
Be less aggressive with `DroplessArena`/`TypedArena` growth.
`DroplessArena` and `TypedArena` use an aggressive growth strategy: the first chunk is 4 KiB, the second is 8 KiB, and it keeps on doubling indefinitely. DHAT profiles show that sometimes this results in large chunks (e.g. 16-128 MiB) that are barely filled.
This commit changes things so that the doubling stops at 2 MiB. This is large enough that chunk allocations are still rare (you might get 100s instead of 10s of them) but avoids lots of unused space in the worst case. It makes the same change to `TypedArena`, too.
I also did some refactoring, as I kept being confused by all the parameters to `intern_shallow`, some of which have invalid combinations (such as a mutable const). So instead `InternMode` now contains all the information that is needed and invalid combinations are ruled out by the type system.
Also I removed interpreter errors from interning. We already ignored almost all errors, and the `ValidationFailure` errors that we handled separately actually cannot ever happen here. The only interpreter failure that was actually reachable was the UB on dangling pointers -- and arguably, a dangling raw pointer is not UB, so the error was not even correct. It's just that the rest of the compiler does not like "dangling" `AllocId`.
It should be possible to review the 3 commits separately.
bors [Sat, 16 May 2020 00:44:57 +0000 (00:44 +0000)]
Auto merge of #72251 - Dylan-DPC:rollup-4mik3o7, r=Dylan-DPC
Rollup of 9 pull requests
Successful merges:
- #71662 (Implement FromStr for OsString)
- #71677 (Add explicit references to the BuildHasher trait)
- #71724 (Doc alias improvements)
- #71948 (Suggest to await future before ? operator)
- #72090 (rustc_driver: factor out computing the exit code)
- #72206 (Cleanup stale 'FIXME(#64197)')
- #72218 (make sure even unleashed miri does not do pointer stuff)
- #72220 ([const-prop] Don't replace Rvalues that are already constants)
- #72224 (doc: add links to rotate_(left|right))