Rollup of 7 pull requests #100974
Closed
Rollup of 7 pull requests #100974
Conversation
This file contains 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
…ister Enable raw-dylib for bin crates Fixes rust-lang#93842 When `raw-dylib` is used in a `bin` crate, we need to collect all of the `raw-dylib` functions, generate the import library and add that to the linker command line. I also changed the tests so that 1) the C++ dlls are created after the Rust dlls, thus there is no chance of accidentally using them in the Rust linking process and 2) disabled generating import libraries when building with MSVC.
Rollup of 7 pull requests Successful merges: - rust-lang#98211 (Implement `fs::get_path` for FreeBSD.) - rust-lang#99353 (Slightly improve mismatched GAT where clause error) - rust-lang#99593 (Suggest removing the tuple struct field for the unwrapped value) - rust-lang#99615 (Remove some explicit `self.infcx` for `FnCtxt`, which already derefs into `InferCtxt`) - rust-lang#99711 (Remove reachable coverage without counters) - rust-lang#99718 (Avoid `&str`/`Symbol` to `String` conversions) - rust-lang#99720 (Sync rustc_codegen_cranelift) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
This avoids monomorphizing all linker code for each codegen backend and will allow passing in extra information to the archive builder from the codegen backend.
This is probably the wrong way to do this...
This avoids differences in line endings.
Move test script to y.rs
# Stabilization proposal The feature was implemented in rust-lang#50045 by est31 and has been in nightly since 2018-05-16 (over 4 years now). There are [no open issues][issue-label] other than the tracking issue. There is a strong consensus that `break` is the right keyword and we should not use `return`. There have been several concerns raised about this feature on the tracking issue (other than the one about tests, which has been fixed, and an interaction with try blocks, which has been fixed). 1. nrc's original comment about cost-benefit analysis: rust-lang#48594 (comment) 2. joshtriplett's comments about seeing use cases: rust-lang#48594 (comment) 3. withoutboats's comments that Rust does not need more control flow constructs: rust-lang#48594 (comment) Many different examples of code that's simpler using this feature have been provided: - A lexer by rpjohnst which must repeat code without label-break-value: rust-lang#48594 (comment) - A snippet by SergioBenitez which avoids using a new function and adding several new return points to a function: rust-lang#48594 (comment). This particular case would also work if `try` blocks were stabilized (at the cost of making the code harder to optimize). - Several examples by JohnBSmith: rust-lang#48594 (comment) - Several examples by Centril: rust-lang#48594 (comment) - An example by petrochenkov where this is used in the compiler itself to avoid duplicating error checking code: rust-lang#48594 (comment) - Amanieu recently provided another example related to complex conditions, where try blocks would not have helped: rust-lang#48594 (comment) Additionally, petrochenkov notes that this is strictly more powerful than labelled loops due to macros which accidentally exit a loop instead of being consumed by the macro matchers: rust-lang#48594 (comment) nrc later resolved their concern, mostly because of the aforementioned macro problems. joshtriplett suggested that macros could be able to generate IR directly (rust-lang#48594 (comment)) but there are no open RFCs, and the design space seems rather speculative. joshtriplett later resolved his concerns, due to a symmetry between this feature and existing labelled break: rust-lang#48594 (comment) withoutboats has regrettably left the language team. joshtriplett later posted that the lang team would consider starting an FCP given a stabilization report: rust-lang#48594 (comment) [issue-label]: https://github.com/rust-lang/rust/issues?q=is%3Aissue+is%3Aopen+label%3AF-label_break_value+ ## Report + Feature gate: - https://github.com/rust-lang/rust/blob/d695a497bbf4b20d2580b75075faa80230d41667/src/test/ui/feature-gates/feature-gate-label_break_value.rs + Diagnostics: - https://github.com/rust-lang/rust/blob/6b2d3d5f3cd1e553d87b5496632132565b6779d3/compiler/rustc_parse/src/parser/diagnostics.rs#L2629 - https://github.com/rust-lang/rust/blob/f65bf0b2bb1a99f73095c01a118f3c37d3ee614c/compiler/rustc_resolve/src/diagnostics.rs#L749 - https://github.com/rust-lang/rust/blob/f65bf0b2bb1a99f73095c01a118f3c37d3ee614c/compiler/rustc_resolve/src/diagnostics.rs#L1001 - https://github.com/rust-lang/rust/blob/111df9e6eda1d752233482c1309d00d20a4bbf98/compiler/rustc_passes/src/loops.rs#L254 - https://github.com/rust-lang/rust/blob/d695a497bbf4b20d2580b75075faa80230d41667/compiler/rustc_parse/src/parser/expr.rs#L2079 - https://github.com/rust-lang/rust/blob/d695a497bbf4b20d2580b75075faa80230d41667/compiler/rustc_parse/src/parser/expr.rs#L1569 + Tests: - https://github.com/rust-lang/rust/blob/master/src/test/ui/label/label_break_value_continue.rs - https://github.com/rust-lang/rust/blob/master/src/test/ui/label/label_break_value_unlabeled_break.rs - https://github.com/rust-lang/rust/blob/master/src/test/ui/label/label_break_value_illegal_uses.rs - https://github.com/rust-lang/rust/blob/master/src/test/ui/lint/unused_labels.rs - https://github.com/rust-lang/rust/blob/master/src/test/ui/run-pass/for-loop-while/label_break_value.rs ## Interactions with other features Labels follow the hygiene of local variables. label-break-value is permitted within `try` blocks: ```rust let _: Result<(), ()> = try { 'foo: { Err(())?; break 'foo; } }; ``` label-break-value is disallowed within closures, generators, and async blocks: ```rust 'a: { || break 'a //~^ ERROR use of unreachable label `'a` //~| ERROR `break` inside of a closure } ``` label-break-value is disallowed on [_BlockExpression_]; it can only occur as a [_LoopExpression_]: ```rust fn labeled_match() { match false 'b: { //~ ERROR block label not supported here _ => {} } } macro_rules! m { ($b:block) => { 'lab: $b; //~ ERROR cannot use a `block` macro fragment here unsafe $b; //~ ERROR cannot use a `block` macro fragment here |x: u8| -> () $b; //~ ERROR cannot use a `block` macro fragment here } } fn foo() { m!({}); } ``` [_BlockExpression_]: https://doc.rust-lang.org/nightly/reference/expressions/block-expr.html [_LoopExpression_]: https://doc.rust-lang.org/nightly/reference/expressions/loop-expr.html
Support compiling codegen units in parallel
According to rust-lang#100960 (comment), this selector is only really intended to apply to item info. However, it's so broad that it's hard to tell when it deliberately applies vs where it accidentally applies.
… r=petrochenkov Stabilize `#![feature(label_break_value)]` See the stabilization report in rust-lang#48594 (comment).
Uplift `clippy::for_loops_over_fallibles` lint into rustc
This PR, as the title suggests, uplifts [`clippy::for_loops_over_fallibles`] lint into rustc. This lint warns for code like this:
```rust
for _ in Some(1) {}
for _ in Ok::<_, ()>(1) {}
```
i.e. directly iterating over `Option` and `Result` using `for` loop.
There are a number of suggestions that this PR adds (on top of what clippy suggested):
1. If the argument (? is there a better name for that expression) of a `for` loop is a `.next()` call, then we can suggest removing it (or rather replacing with `.by_ref()` to allow iterator being used later)
```rust
for _ in iter.next() {}
// turns into
for _ in iter.by_ref() {}
```
2. (otherwise) We can suggest using `while let`, this is useful for non-iterator, iterator-like things like [async] channels
```rust
for _ in rx.recv() {}
// turns into
while let Some(_) = rx.recv() {}
```
3. If the argument type is `Result<impl IntoIterator, _>` and the body has a `Result<_, _>` type, we can suggest using `?`
```rust
for _ in f() {}
// turns into
for _ in f()? {}
```
4. To preserve the original behavior and clear intent, we can suggest using `if let`
```rust
for _ in f() {}
// turns into
if let Some(_) = f() {}
```
(P.S. `Some` and `Ok` are interchangeable depending on the type)
I still feel that the lint wording/look is somewhat off, so I'll be happy to hear suggestions (on how to improve suggestions :D)!
Resolves rust-lang#99272
[`clippy::for_loops_over_fallibles`]: https://rust-lang.github.io/rust-clippy/master/index.html#for_loops_over_fallibles
…-higher-up, r=oli-obk let-else: break out to one scope higher for let-else ``@est31`` This PR follows up with rust-lang#99518 which is to break out to the last remainder scope. It breaks to the out-most `region_scope` of the block if the first statement is a `let-else`.
…ebank Parser will not suggest invalid expression when use public Fixes rust-lang#100165
…s, r=davidtwco save_analysis: Migrate diagnostic * Migrate the `rustc_save_analysis` crate's diagnostic to translatable diagnostic structs. Depends on rust-lang#100694 and rust-lang#100754 for #[fatal(..)] support, then rust-lang@aa68eb4, rust-lang@f5219a3, rust-lang@7da52f6 can be removed. (I copied commits from rust-lang#100754)
… r=GuillaumeGomez rustdoc: ayu code color selector more specific According to rust-lang#100960 (comment), this selector is only really intended to apply to item info. However, it's so broad that it's hard to tell when it deliberately applies vs where it accidentally applies.
…bjorn3 Sync rustc_codegen_cranelift The main highlights this time are support for parallel compilation of codegen units (by me) and improved windows support (by `@afonso360)` In addition `@afonso360` added abi-checker to cg_clif's CI. This has already catched an abi compatibility issue with AArch64. The fix has landed on Cranelift's main branch, but doesn't yet have a release. `@uweigand` also submitted a couple of PR's that will are prerequisites for supporting IBM's s390x architecture. r? `@ghost` `@rustbot` label +A-codegen +A-cranelift +T-compiler
rustbot
added
A-translation
|
@bors r+ p=7 rollup=never |
bors
added
the
S-waiting-on-bors
|
The job Click to see the possible cause of the failure (guessed by this bot) |
davidtwco
removed
the
A-translation
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.
Successful merges:
#![feature(label_break_value)]#99332 (Stabilize#![feature(label_break_value)])clippy::for_loops_over_fallibleslint into rustc #99696 (Upliftclippy::for_loops_over_fallibleslint into rustc)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup