update from upstream #1
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
unused_unit: lint also in type parameters and where clauses changelog: unused_unit now also lints in type parameters and where clauses Fixes #5585
Before:
TokenStream [
Ident {
ident: "name",
span: #0 bytes(37..41),
},
Punct {
ch: '=',
spacing: Alone,
span: #0 bytes(42..43),
},
Literal { lit: Lit { kind: Str, symbol: "SNPP", suffix: None }, span: Span { lo: BytePos(44), hi: BytePos(50), ctxt: #0 } },
Punct {
ch: ',',
spacing: Alone,
span: #0 bytes(50..51),
},
Ident {
ident: "owner",
span: #0 bytes(56..61),
},
Punct {
ch: '=',
spacing: Alone,
span: #0 bytes(62..63),
},
Literal { lit: Lit { kind: Str, symbol: "Canary M Burns", suffix: None }, span: Span { lo: BytePos(64), hi: BytePos(80), ctxt: #0 } },
]
After:
TokenStream [
Ident {
ident: "name",
span: #0 bytes(37..41),
},
Punct {
ch: '=',
spacing: Alone,
span: #0 bytes(42..43),
},
Literal {
kind: Str,
symbol: "SNPP",
suffix: None,
span: #0 bytes(44..50),
},
Punct {
ch: ',',
spacing: Alone,
span: #0 bytes(50..51),
},
Ident {
ident: "owner",
span: #0 bytes(56..61),
},
Punct {
ch: '=',
spacing: Alone,
span: #0 bytes(62..63),
},
Literal {
kind: Str,
symbol: "Canary M Burns",
suffix: None,
span: #0 bytes(64..80),
},
]
…ge of terminology.
Downgrade useless_let_if_seq to nursery
I feel that this lint has the wrong balance of incorrect suggestions for a default-enabled lint.
The immediate code I faced was something like:
```rust
fn main() {
let mut good = do1();
if !do2() {
good = false;
}
if good {
println!("good");
}
}
fn do1() -> bool { println!("1"); false }
fn do2() -> bool { println!("2"); false }
```
On this code Clippy calls it unidiomatic and suggests the following diff, which has different behavior in a way that I don't necessarily want.
```diff
- let mut good = do1();
- if !do2() {
- good = false;
- }
+ let good = if !do2() {
+ false
+ } else {
+ do1()
+ };
```
On exploring issues filed about this lint, I have found that other users have also struggled with inappropriate suggestions (rust-lang/rust-clippy#4124, rust-lang/rust-clippy#3043, rust-lang/rust-clippy#2918, rust-lang/rust-clippy#2176) and suggestions that make the code worse (rust-lang/rust-clippy#3769, rust-lang/rust-clippy#2749). Overall I believe that this lint is still at nursery quality for now and should not be enabled.
---
changelog: Remove useless_let_if_seq from default set of enabled lints
Implement FromStr for OsString
Add explicit references to the BuildHasher trait Fixes #71652
…ie27 Doc alias improvements After [this message](#50146 (comment)), 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. r? @ollie27 cc @rust-lang/rustdoc
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.
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.
…ochenkov Cleanup stale 'FIXME(#64197)' (My first PR in rust-lang, any feedback is welcome. Please don't hesitate to let me know if I'm trying to do something pointless!) Trivial cleanup of a stale `FIXME`, `StringReader.pos` is no longer exposed. For testing added `pos()` method that returns cloned value of `pos`.
make sure even unleashed miri does not do pointer stuff r? @oli-obk
[const-prop] Don't replace Rvalues that are already constants This cleans up a few mir-opt tests which have slight changes to spans for `consts` as a result of replacing them with new Rvalues.
doc: add links to rotate_(left|right)
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)) Failed merges: r? @ghost
The value passed in already has backticks surrounding the text.
update stacker to 0.1.9 to unbreak build on OpenBSD the version 0.1.8 of stacker (what is currently pinned in Cargo.lock) doesn't build on OpenBSD (see rust-lang/stacker#34). update the version to 0.1.9
Signed-off-by: Rustin-Liu <[email protected]>
Miri interning: replace ICEs by proper errors Fixes #71316 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. r? @oli-obk Cc @rust-lang/wg-const-eval
identity_op: allow `1 << 0` I went for accepting `1 << 0` verbatim instead of something more general as it seems to be what everyone in the issue thread needed. changelog: identity_op: allow `1 << 0` as it's a common pattern in bit manipulation code. Fixes #3430
Fix comparison_chain false positive changelog: comparison_chain: fix false positives when the binary operation is the same. Fixes #5212
Introduce `enum CodeModel` instead.
Workaround MSYS2/chocolatey issue again
Rollup of 6 pull requests Successful merges: - #71863 (Suggest fixes and add error recovery for `use foo::self`) - #72139 (Make `fold` standalone.) - #72275 (Continue lowering for unsupported async generator instead of returning an error.) - #72361 (split_inclusive: add tracking issue number (72360)) - #72364 (Remove unused dependencies) - #72366 (Adjust the zero check in `RawVec::grow`.) Failed merges: r? @ghost
Update to LLVM 10 LLVM 10 is going to be branched soon, so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted, but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](llvm/llvm-project@192cce1) the patch. * [ ] Even with the revert, there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135, https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.
Use `T`'s discriminant type in `mem::Discriminant<T>` instead of `u64`. fixes #70509 Adds the lang-item `discriminant_kind`. Updates the function signature of `intrinsics::discriminant_value`. Adds the *probably permanently unstable* trait `DiscriminantKind`. `mem::Discriminant` should now be smaller in some cases. r? @ghost
Dumb NRVO This is a very simple version of an NRVO pass, which scans backwards from the `return` terminator to see if there is an an assignment like `_0 = _1`. If a basic block with two or more predecessors is encountered during this scan without first seeing an assignment to the return place, we bail out. This avoids running a full "reaching definitions" dataflow analysis. I wanted to see how much `rustc` would benefit from even a very limited version of this optimization. We should be able to use this as a point of comparison for more advanced versions that are based on live ranges. r? @ghost
…nieu Make `std::char` functions and constants associated to `char`. First step to fix #71763.
rustc-book: Document `-Z strip=val` option cc #72110
…behaviour, r=kinnison Fix going back in history to a search result page on firefox This bug was actually firefox not re-running JS script when you go back in history. To trigger it on the current docs: * Make a search * Pick an element (which isn't on the same page as the current element!) * Go back in history Instead of having the search results, you'll see the normal doc page. You can find a small explanation about it [here](http://web.archive.org/web/20100428053932/http://www.firefoxanswer.com/firefox/672-firefoxanswer.html). r? @kinnison cc @ollie27
Suggest installing VS Build Tools in more situations When MSVC's `link.exe` wasn't found but another `link.exe` was, the error message given can be [impenetrable](https://pastebin.com/MRMCr7HM) to many users. The usual suspect is GNU's `link` tool. In this case, inform the user that they may need to install VS build tools. This only applies when Microsoft's link tool is expected.
…c-morse Remove unused `StableHashingContext::node_to_hir_id` method cc #50928
FIX - Char documentation for unexperienced users This is my first PR on rust and even if I've read [CONTRIBUTING.md](https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#pull-requests) I'm ensure everything is perfect. Sorry if I didn't follow the exact procedure. **What it does:** - Add an example in the char documentation **Explanation** Unexperienced users might not know that punctuation is `Case_Ignorable` and not `Uppercase` and `Lowercase` which mean that when checking if a string is uppercase one might be tempted to write: ```rust my_string.chars().all(char::is_uppercase) ``` However this will return false for `"HELLO WORLD"` which is not intuitive. Since the function `is_case_ignorable` doesn't exists I believe the correct way to check is: ```rust !my_string.chars().any(char::is_lowercase) ``` The aim of this example is to prevent unexperienced users to make an error which punctuation chars.
llvm: Expose tiny code model to users This model is relevant to embedded AArch64 targets and was added to LLVM relatively recently (https://reviews.llvm.org/D49673, mid 2018), so rustc frontend didn't provide access to it with `-C code-model`. The gcc analogue is [`-mcmodel=tiny`](https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html). (This is one of the options that are passed directly to LLVM without being interpreted by rustc.) Follow up to #72248.
Rollup of 7 pull requests Successful merges: - #71854 (Make `std::char` functions and constants associated to `char`.) - #72111 (rustc-book: Document `-Z strip=val` option) - #72272 (Fix going back in history to a search result page on firefox) - #72296 (Suggest installing VS Build Tools in more situations) - #72365 (Remove unused `StableHashingContext::node_to_hir_id` method) - #72371 (FIX - Char documentation for unexperienced users) - #72397 (llvm: Expose tiny code model to users) Failed merges: r? @ghost
Experimentally add `ffi_const` and `ffi_pure` extern fn attributes Add FFI function attributes corresponding to clang/gcc/... `const` and `pure`. Rebased version of #58327 by @gnzlbg with the following changes: - Switched back from the `c_ffi_const` and `c_ffi_pure` naming to `ffi_const` and `ffi_pure`, as I agree with #58327 (comment) and this nicely aligns with `ffi_returns_twice` - (Hopefully) took care of all of @hanna-kruppe's change requests in the original PR r? @hanna-kruppe
De-abuse TyKind::Error in exhaustiveness checking Replaces #71074. Context: #70866. In order to remove the use of `TyKind::Error`, I had to make sure we skip over those fields whose inhabitedness should not be observed. This is potentially error-prone however, since we must be careful not to mix filtered and unfiltered lists of patterns. I managed to hide away most of the filtering behind a new `Fields` struct, that I used everywhere relevant. I quite like the result; I think the twin concepts of `Constructor` and `Fields` make a good mental model. As usual, I tried to separate commits that shuffle code around from commits that require more thought to review. cc @varkor @Centril
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.