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: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))
Dylan DPC [Sat, 16 May 2020 00:37:23 +0000 (02:37 +0200)]
Rollup merge of #72090 - RalfJung:rustc_driver-exit-code, r=oli-obk
rustc_driver: factor out computing the exit code
In a recent Miri PR I [added a convenience wrapper](https://github.com/rust-lang/miri/pull/1405/files#diff-c3d602c5c8035a16699ce9c015bfeceaR125) around `catch_fatal_errors` and `run_compiler` that @oli-obk suggested I could upstream. However, after seeing what could be shared between `rustc_driver::main`, clippy and Miri, really the only thing I found is computing the exit code -- so that's what this PR does.
What prevents using the Miri convenience function in `rustc_driver::main` and clippy is that they do extra work inside `catch_fatal_errors`, and while I could abstract that away, clippy actually *computes the callbacks* inside there, and I fond no good way to abstract that and thus gave up. Maybe the clippy thing could be moved out, I am not sure if it ever can actually raise a `FatalErrorMarker` -- someone more knowledgeable in clippy would have to do that.
Dylan DPC [Sat, 16 May 2020 00:37:19 +0000 (02:37 +0200)]
Rollup merge of #71724 - GuillaumeGomez:doc-alias-improvements, r=ollie27
Doc alias improvements
After [this message](https://github.com/rust-lang/rust/issues/50146#issuecomment-496601755), I realized that the **doc alias**. So this PR does the followings:
* Align the alias discovery on items added into the search-index. It brings a few nice advantages:
* Instead of cloning the data between the two (in rustdoc source code), we now have the search-index one and aliases which reference to the first one. So we go from one big map containing a lot of duplicated data to just integers...
* In the front-end (main.js), I improved the code around aliases to allow them to go through the same transformation as other items when we show the search results.
* Improve the search tester in order to perform multiple requests into one file (I think it's better in this case than having a file for each case considering how many there are...)
* I also had to add the new function inside the tester (`handleAliases`)
Once this PR is merged, I intend to finally stabilize this feature.
SOFe [Fri, 15 May 2020 14:41:36 +0000 (22:41 +0800)]
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.
This PR reworks the `Step` trait to be phrased in terms of the *successor* and *predecessor* operations. With this, `Step` hopefully has a consistent identity that can have a path towards stabilization. The proposed trait:
```rust
/// Objects that have a notion of *successor* and *predecessor* operations.
///
/// The *successor* operation moves towards values that compare greater.
/// The *predecessor* operation moves towards values that compare lesser.
///
/// # Safety
///
/// This trait is `unsafe` because its implementation must be correct for
/// the safety of `unsafe trait TrustedLen` implementations, and the results
/// of using this trait can otherwise be trusted by `unsafe` code to be correct
/// and fulful the listed obligations.
pub unsafe trait Step: Clone + PartialOrd + Sized {
/// Returns the number of *successor* steps required to get from `start` to `end`.
///
/// Returns `None` if the number of steps would overflow `usize`
/// (or is infinite, or if `end` would never be reached).
///
/// # Invariants
///
/// For any `a`, `b`, and `n`:
///
/// * `steps_between(&a, &b) == Some(n)` if and only if `Step::forward(&a, n) == Some(b)`
/// * `steps_between(&a, &b) == Some(n)` if and only if `Step::backward(&a, n) == Some(a)`
/// * `steps_between(&a, &b) == Some(n)` only if `a <= b`
/// * Corollary: `steps_between(&a, &b) == Some(0)` if and only if `a == b`
/// * Note that `a <= b` does _not_ imply `steps_between(&a, &b) != None`;
/// this is the case wheen it would require more than `usize::MAX` steps to get to `b`
/// * `steps_between(&a, &b) == None` if `a > b`
fn steps_between(start: &Self, end: &Self) -> Option<usize>;
/// Returns the value that would be obtained by taking the *successor*
/// of `self` `count` times.
///
/// If this would overflow the range of values supported by `Self`, returns `None`.
///
/// # Invariants
///
/// For any `a`, `n`, and `m`:
///
/// * `Step::forward_checked(a, n).and_then(|x| Step::forward_checked(x, m)) == Step::forward_checked(a, m).and_then(|x| Step::forward_checked(x, n))`
///
/// For any `a`, `n`, and `m` where `n + m` does not overflow:
///
/// * `Step::forward_checked(a, n).and_then(|x| Step::forward_checked(x, m)) == Step::forward_checked(a, n + m)`
///
/// For any `a` and `n`:
///
/// * `Step::forward_checked(a, n) == (0..n).try_fold(a, |x, _| Step::forward_checked(&x, 1))`
/// * Corollary: `Step::forward_checked(&a, 0) == Some(a)`
fn forward_checked(start: Self, count: usize) -> Option<Self>;
/// Returns the value that would be obtained by taking the *successor*
/// of `self` `count` times.
///
/// If this would overflow the range of values supported by `Self`,
/// this function is allowed to panic, wrap, or saturate.
/// The suggested behavior is to panic when debug assertions are enabled,
/// and to wrap or saturate otherwise.
///
/// Unsafe code should not rely on the correctness of behavior after overflow.
///
/// # Invariants
///
/// For any `a`, `n`, and `m`, where no overflow occurs:
///
/// * `Step::forward(Step::forward(a, n), m) == Step::forward(a, n + m)`
///
/// For any `a` and `n`, where no overflow occurs:
///
/// * `Step::forward_checked(a, n) == Some(Step::forward(a, n))`
/// * `Step::forward(a, n) == (0..n).fold(a, |x, _| Step::forward(x, 1))`
/// * Corollary: `Step::forward(a, 0) == a`
/// * `Step::forward(a, n) >= a`
/// * `Step::backward(Step::forward(a, n), n) == a`
fn forward(start: Self, count: usize) -> Self {
Step::forward_checked(start, count).expect("overflow in `Step::forward`")
}
/// Returns the value that would be obtained by taking the *successor*
/// of `self` `count` times.
///
/// # Safety
///
/// It is undefined behavior for this operation to overflow the
/// range of values supported by `Self`. If you cannot guarantee that this
/// will not overflow, use `forward` or `forward_checked` instead.
///
/// # Invariants
///
/// For any `a`:
///
/// * if there exists `b` such that `b > a`, it is safe to call `Step::forward_unchecked(a, 1)`
/// * if there exists `b`, `n` such that `steps_between(&a, &b) == Some(n)`,
/// it is safe to call `Step::forward_unchecked(a, m)` for any `m <= n`.
///
/// For any `a` and `n`, where no overflow occurs:
///
/// * `Step::forward_unchecked(a, n)` is equivalent to `Step::forward(a, n)`
#[unstable(feature = "unchecked_math", reason = "niche optimization path", issue = "none")]
unsafe fn forward_unchecked(start: Self, count: usize) -> Self {
Step::forward(start, count)
}
/// Returns the value that would be obtained by taking the *successor*
/// of `self` `count` times.
///
/// If this would overflow the range of values supported by `Self`, returns `None`.
///
/// # Invariants
///
/// For any `a`, `n`, and `m`:
///
/// * `Step::backward_checked(a, n).and_then(|x| Step::backward_checked(x, m)) == n.checked_add(m).and_then(|x| Step::backward_checked(a, x))`
/// * `Step::backward_checked(a, n).and_then(|x| Step::backward_checked(x, m)) == try { Step::backward_checked(a, n.checked_add(m)?) }`
///
/// For any `a` and `n`:
///
/// * `Step::backward_checked(a, n) == (0..n).try_fold(a, |x, _| Step::backward_checked(&x, 1))`
/// * Corollary: `Step::backward_checked(&a, 0) == Some(a)`
fn backward_checked(start: Self, count: usize) -> Option<Self>;
/// Returns the value that would be obtained by taking the *predecessor*
/// of `self` `count` times.
///
/// If this would overflow the range of values supported by `Self`,
/// this function is allowed to panic, wrap, or saturate.
/// The suggested behavior is to panic when debug assertions are enabled,
/// and to wrap or saturate otherwise.
///
/// Unsafe code should not rely on the correctness of behavior after overflow.
///
/// # Invariants
///
/// For any `a`, `n`, and `m`, where no overflow occurs:
///
/// * `Step::backward(Step::backward(a, n), m) == Step::backward(a, n + m)`
///
/// For any `a` and `n`, where no overflow occurs:
///
/// * `Step::backward_checked(a, n) == Some(Step::backward(a, n))`
/// * `Step::backward(a, n) == (0..n).fold(a, |x, _| Step::backward(x, 1))`
/// * Corollary: `Step::backward(a, 0) == a`
/// * `Step::backward(a, n) <= a`
/// * `Step::forward(Step::backward(a, n), n) == a`
fn backward(start: Self, count: usize) -> Self {
Step::backward_checked(start, count).expect("overflow in `Step::backward`")
}
/// Returns the value that would be obtained by taking the *predecessor*
/// of `self` `count` times.
///
/// # Safety
///
/// It is undefined behavior for this operation to overflow the
/// range of values supported by `Self`. If you cannot guarantee that this
/// will not overflow, use `backward` or `backward_checked` instead.
///
/// # Invariants
///
/// For any `a`:
///
/// * if there exists `b` such that `b < a`, it is safe to call `Step::backward_unchecked(a, 1)`
/// * if there exists `b`, `n` such that `steps_between(&b, &a) == Some(n)`,
/// it is safe to call `Step::backward_unchecked(a, m)` for any `m <= n`.
///
/// For any `a` and `n`, where no overflow occurs:
///
/// * `Step::backward_unchecked(a, n)` is equivalent to `Step::backward(a, n)`
#[unstable(feature = "unchecked_math", reason = "niche optimization path", issue = "none")]
unsafe fn backward_unchecked(start: Self, count: usize) -> Self {
Step::backward(start, count)
}
}
```
Note that all of these are associated functions and not callable via method syntax; the calling syntax is always `Step::forward(start, n)`. This version of the trait additionally changes the stepping functions to talk their arguments by value.
As opposed to previous attempts which provided a "step by one" method directly, this version of the trait only exposes "step by n". There are a few reasons for this:
- `Range*`, the primary consumer of `Step`, assumes that the "step by n" operation is cheap. If a single step function is provided, it will be a lot more enticing to implement "step by n" as n repeated calls to "step by one". While this is not strictly incorrect, this behavior would be surprising for anyone used to using `Range<{primitive integer}>`.
- With a trivial default impl, this can be easily added backwards-compatibly later.
- The debug-wrapping "step by n" needs to exist for `RangeFrom` to be consistent between "step by n" and "step by one" operation. (Note: the behavior is not changed by this PR, but making the behavior consistent is made tenable by this PR.)
Three "kinds" of step are provided: `_checked`, which returns an `Option` indicating attempted overflow; (unsuffixed), which provides "safe overflow" behavior (is allowed to panic, wrap, or saturate, depending on what is most convenient for a given type); and `_unchecked`, which is a version which assumes overflow does not happen.
Review is appreciated to check that:
- The invariants as described on the `Step` functions are enough to specify the "common sense" consistency for successor/predecessor.
- Implementation of `Step` functions is correct in the face of overflow and the edges of representable integers.
- Added tests of `Step` functions are asserting the correct behavior (and not just the implemented behavior).
Dylan DPC [Thu, 14 May 2020 23:57:17 +0000 (01:57 +0200)]
Rollup merge of #72146 - Mark-Simulacrum:separate-std-asserts, r=alexcrichton
Provide separate option for std debug asserts
On local one-off benchmarking of libcore metadata-only, debug asserts in std are a significant hit (15s to 20s). Provide an option for compiler developers to disable them. A build with a nightly compiler is around 10s, for reference.
Dylan DPC [Thu, 14 May 2020 23:57:15 +0000 (01:57 +0200)]
Rollup merge of #72062 - overdrivenpotato:psp, r=jonas-schievink
Add built in PSP target
This adds a new target, `mipsel-sony-psp`, corresponding to the Sony PSP. The linker script is necessary to handle special sections, which are required by the target. This has been tested with my [rust-psp] crate and I can confirm it works as intended.
The linker script is taken from [here]. It has been slightly adapted to work with rust and LLD.
The `stdarch` submodule was also updated in order for `libcore` to build successfully.
bors [Thu, 14 May 2020 23:22:47 +0000 (23:22 +0000)]
Auto merge of #71321 - matthewjasper:alloc-min-spec, r=sfackler
Use min_specialization in liballoc
- Remove a type parameter from `[A]RcFromIter`.
- Remove an implementation of `[A]RcFromIter` that didn't actually
specialize anything.
- Remove unused implementation of `IsZero` for `Option<&mut T>`.
- Change specializations of `[A]RcEqIdent` to use a marker trait version
of `Eq`.
- Remove `BTreeClone`. I couldn't find a way to make this work with
`min_specialization`.
- Add `rustc_unsafe_specialization_marker` to `Copy` and `TrustedLen`.
After this only libcore is the only standard library crate using `feature(specialization)`.
cc #31844
JOE1994 [Thu, 14 May 2020 20:39:36 +0000 (16:39 -0400)]
Minor fixes to comments
* In 'src/librustc_ast_passes/node_count.rs'
* typo fix ('rought' -> 'rough')
* In 'src/librustc_middle/middle/region.rs',
* fixed broken link to 'rustc-dev-guide'
* typo fix ('aluded' -> 'alluded')
bors [Thu, 14 May 2020 19:35:24 +0000 (19:35 +0000)]
Auto merge of #72202 - Dylan-DPC:rollup-6lbxh1s, r=Dylan-DPC
Rollup of 8 pull requests
Successful merges:
- #71910 (Fix unused_parens false positive when using binary operations)
- #72087 (Fix hang in lexical_region_resolve)
- #72126 (Change `WorkProduct::saved_files` to an `Option`.)
- #72127 (add long error explanation for E0228)
- #72141 (Warn against thread::sleep in async fn)
- #72170 (use `require_lang_item` over `unwrap`.)
- #72191 (Clean up E0589 explanation)
- #72194 (Don't ICE on missing `Unsize` impl)
would generate an ICE due to the missing `Unsize` impl being run through the `suggest_change_mut` suggestion. This PR adds an early exit and a pointer to the appropriate docs regarding `Unsize` instead:
```
error[E0277]: the trait bound `&'a T: std::marker::Unsize<&'a U>` is not satisfied
--> src/test/ui/issues/issue-71036.rs:11:1
|
11 | impl<'a, T: ?Sized + Unsize<U>, U: ?Sized> DispatchFromDyn<Foo<'a, U>> for Foo<'a, T> {}
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `std::marker::Unsize<&'a U>` is not implemented for `&'a T`
|
= note: all implementations of `Unsize` are provided automatically by the compiler, see <https://doc.rust-lang.org/stable/std/marker/trait.Unsize.html> for more information
= note: required because of the requirements on the impl of `std::ops::DispatchFromDyn<&'a &'a U>` for `&'a &'a T`
error: aborting due to previous error
For more information about this error, try `rustc --explain E0277`.
```
Dylan DPC [Thu, 14 May 2020 16:21:53 +0000 (18:21 +0200)]
Rollup merge of #72141 - kornelski:dontsleep, r=joshtriplett
Warn against thread::sleep in async fn
I've seen `thread::sleep` wrecking havoc in async servers. There's already an [issue for clippy](https://github.com/rust-lang/rust-clippy/issues/4377), but the std docs could warn against it too.
Guillaume Gomez [Wed, 13 May 2020 15:03:37 +0000 (17:03 +0200)]
* Update aliases data struct from HashMap to BTreeMap to have more deterministic results
* Update Javascript to take this change into account
* Update CrateData::aliases field to take a reference instead (it allowed to remove a conversion loop)
3 commits in ed22e6fbfcb6ce436e9ea3b4bb4a55b2fb50a57e..892b928b565e35d25b6f9c47faee03b94bc41489
2020-04-24 12:46:22 -0700 to 2020-05-11 11:13:51 -0700
- clarify that str data must still be initialized
- remove language-level UB for non-UTF-8 str
- Replace incorrect term "parent modules" with "ancestor modules". (rust-lang/reference#806)
Ralf Jung [Thu, 14 May 2020 08:22:54 +0000 (10:22 +0200)]
Rollup merge of #71964 - jcotton42:bootstrap_decode_none_windows, r=Mark-Simulacrum
Fix bootstrap failing on win32
```powershell
python x.py -h # or really any x.py command
```
would fail with
```
info: Downloading and building bootstrap before processing --help
command. See src/bootstrap/README.md for help with common
commands.
Updating only changed submodules
Submodules updated in 0.15 seconds
Traceback (most recent call last):
File "x.py", line 11, in <module>
bootstrap.main()
File "C:\Users\Joshua\Projects\forks\rust\src\bootstrap\bootstrap.py", line 960, in main
bootstrap(help_triggered)
File "C:\Users\Joshua\Projects\forks\rust\src\bootstrap\bootstrap.py", line 925, in bootstrap
build.build = args.build or build.build_triple()
File "C:\Users\Joshua\Projects\forks\rust\src\bootstrap\bootstrap.py", line 731, in build_triple
return default_build_triple()
File "C:\Users\Joshua\Projects\forks\rust\src\bootstrap\bootstrap.py", line 184, in default_build_triple
ostype = require(["uname", "-s"], exit=required).decode(default_encoding)
AttributeError: 'NoneType' object has no attribute 'decode'
```
This PR defers the `decode` call until after we're sure `ostype` and `cputype` are not `None`, as they would be on Windows since `uname` doesn't exist
Ralf Jung [Thu, 14 May 2020 08:22:50 +0000 (10:22 +0200)]
Rollup merge of #71870 - ltratt:more_specific_type_name_doc, r=kennytm
Be slightly more precise about any::type_name()'s guarantees.
The first commit in this PR rephrases the current documentation for `any::type_name()` to be a little more specific about the guarantees (or lack thereof) that this function makes. The second commit explicitly documents that lifetimes are currently not included in the output (since this bit me particularly hard recently).
bors [Thu, 14 May 2020 06:22:40 +0000 (06:22 +0000)]
Auto merge of #69756 - wesleywiser:simplify_try, r=oli-obk
Modify SimplifyArmIdentity so it can trigger on mir-opt-level=1
I also added test cases to make sure the optimization can fire on all of
these cases:
```rust
fn case_1(o: Option<u8>) -> Option<u8> {
match o {
Some(u) => Some(u),
None => None,
}
}
fn case2(r: Result<u8, i32>) -> Result<u8, i32> {
match r {
Ok(u) => Ok(u),
Err(i) => Err(i),
}
}
fn case3(r: Result<u8, i32>) -> Result<u8, i32> {
let u = r?;
Ok(u)
}
```
Without MIR inlining, this still does not completely optimize away the
`?` operator because the `Try::into_result()`, `From::from()` and
`Try::from_error()` calls still exist. This does move us a bit closer to
that goal though because:
- We can now run the pass on mir-opt-level=1
- We no longer depend on the copy propagation pass running which is
unlikely to stabilize anytime soon.
bors [Thu, 14 May 2020 02:50:34 +0000 (02:50 +0000)]
Auto merge of #72058 - RalfJung:no-dist-lldb, r=Mark-Simulacrum
bootstrap: remove lldb dist packaging
The lldb-preview rustup package is missing on every single target, and has never been shipped beyond x86_64-apple-darwin. It was removed in #62592 which landed around a year ago, and there's not been demand that we re-enable it since, so we're now removing support entirely to cleanup the code a bit.
The hope is that this will also kill the useless "lldb-preview" row on https://rust-lang.github.io/rustup-components-history/.
We should establish a process on how often and when to update Clippy. (After X feature PRs? Once per week? Only on bug fixes and in the release week? ...?)
bors [Wed, 13 May 2020 14:29:56 +0000 (14:29 +0000)]
Auto merge of #72013 - nnethercote:make-RawVec-grow-mostly-non-generic, r=Amanieu
Make `RawVec::grow` mostly non-generic.
`cargo-llvm-lines` shows that, in various benchmarks, `RawVec::grow` is
instantiated 10s or 100s of times and accounts for 1-8% of lines of
generated LLVM IR.
This commit moves most of `RawVec::grow` into a separate function that
isn't parameterized by `T`, which means it doesn't need to be
instantiated many times. This reduces compile time significantly.
projects / rust.git / log