- 
                Notifications
    You must be signed in to change notification settings 
- Fork 13.9k
Rollup of 12 pull requests #120279
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
          
     Closed
      
      
    
                
     Closed
            
            Rollup of 12 pull requests #120279
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
    
  
  
    
    Don't skip the inconsistent data layout check for custom LLVMs. With rust-lang#118708, all targets will have a simple test that would trigger this check if LLVM's data layouts do change - so data layouts would be corrected during the LLVM upgrade. Therefore, with builtin targets, this check won't trigger with our LLVM because each target will have been confirmed to work. With non-builtin targets, this check is probably useful to have because you can change the data layout in your target and if its wrong then that could lead to bugs. When using a custom LLVM, the same justification makes sense for non-builtin targets as with our LLVM, the user can update their target to match their LLVM and that's probably a good thing to do. However, with a custom LLVM, the user cannot change the builtin target data layouts if they don't match - though given that the compiler's data layout is used for layout computation and a bunch of other things - you could get some bugs because of the mismatch and probably want to know about that. `CFG_LLVM_ROOT` was also always set during local development with `download-ci-llvm` so this bug would never trigger locally. Signed-off-by: David Wood <david@davidtw.co>
When encountering
```rust
let _ = if true {
    Struct
} else {
    foo() // -> Box<dyn Trait>
};
```
if `Struct` implements `Trait`, suggest boxing the then arm tail expression.
Part of rust-lang#102629.
    Rename `link_(dylib,framework)`, remove `link_rust_dylib`.
Rename `link(_whole)(staticlib,rlib)` to something more suitable.
…olving `impl Trait`
When encountering the following
```rust
// run-rustfix
trait Trait {}
struct Struct;
impl Trait for Struct {}
fn foo() -> Box<dyn Trait> {
    Box::new(Struct)
}
fn bar() -> impl Trait {
    Struct
}
fn main() {
    let _ = if true {
        Struct
    } else {
        foo() //~ ERROR E0308
    };
    let _ = if true {
        foo()
    } else {
        Struct //~ ERROR E0308
    };
    let _ = if true {
        Struct
    } else {
        bar() // impl Trait
    };
    let _ = if true {
        bar() // impl Trait
    } else {
        Struct
    };
}
```
suggest boxing both arms
```rust
    let _ = if true {
        Box::new(Struct) as Box<dyn Trait>
    } else {
        Box::new(bar())
    };
    let _ = if true {
        Box::new(bar()) as Box<dyn Trait>
    } else {
        Box::new(Struct)
    };
```
    linker: Refactor library linking methods in `trait Linker` Linkers are not aware of Rust libraries, they look like regular static or dynamic libraries to them, so Rust-specific methods in `trait Linker` do not make much sense. They can be either removed or renamed to something more suitable. Commits after the second one are cleanups.
…yUwU Do not normalize closure signature when building `FnOnce` shim It is not necessary to normalize the closure signature when building an `FnOnce` shim for an `Fn`/`FnMut` closure. That closure shim is just calling `FnMut::call_mut(&mut self)` anyways. It's also somewhat sketchy that we were ever doing this to begin with, since we're normalizing with a `ParamEnv::reveal_all()` param-env, which is definitely not right with possibly polymorphic substs. This cuts out a tiny bit of unnecessary work in `Instance::resolve` and simplifies the signature because now we can unconditionally return an `Instance`.
…lnay Manually implement derived `NonZero` traits. Step 3 as mentioned in rust-lang#100428 (review). Manually implement the traits that would cause “borrow of layout constrained field with interior mutability” errors when switching to `NonZero<T>`. r? ``@dtolnay``
…ert, r=tmiasko Fix assume and assert in jump threading r? `@tmiasko`
…errors Add `#[coverage(off)]` to closures introduced by `#[test]` and `#[bench]` These closures are an internal implementation detail of the `#[test]` and `#[bench]` attribute macros, so from a user perspective there is no reason to instrument them for coverage. Skipping them makes coverage reports slightly cleaner, and will also allow other changes to span processing during coverage instrumentation, without having to worry about how they affect the `#[test]` macro. The `#[coverage(off)]` attribute has no effect when `-Cinstrument-coverage` is not used. Fixes rust-lang#120046. --- Note that this PR has no effect on the user-written function that has the `#[test]` attribute attached to it. That function will still be instrumented as normal.
…ase, r=petrochenkov add several resolution test cases r? `@petrochenkov`
…diagnostics-uncommon-codepoints, r=Manishearth Split Diagnostics for Uncommon Codepoints: Add List to Display Characters Involved This Pull Request adds a list of the uncommon codepoints involved in the `uncommon_codepoints` lint, as outlined as a first step in rust-lang#120228. Example rendered diagnostic: ``` error: identifier contains an uncommon Unicode codepoint: 'µ' --> $DIR/lint-uncommon-codepoints.rs:3:7 | LL | const µ: f64 = 0.000001; | ^ | note: the lint level is defined here --> $DIR/lint-uncommon-codepoints.rs:1:9 | LL | #![deny(uncommon_codepoints)] | ^^^^^^^^^^^^^^^^^^^ ``` (Retrying rust-lang#120258.)
Provide structured suggestion to use trait objects in some cases of `if` arm type divergence
```
error[E0308]: `if` and `else` have incompatible types
  --> $DIR/suggest-box-on-divergent-if-else-arms.rs:15:9
   |
LL |       let _ = if true {
   |  _____________-
LL | |         Struct
   | |         ------ expected because of this
LL | |     } else {
LL | |         foo()
   | |         ^^^^^ expected `Struct`, found `Box<dyn Trait>`
LL | |     };
   | |_____- `if` and `else` have incompatible types
   |
   = note: expected struct `Struct`
              found struct `Box<dyn Trait>`
help: `Struct` implements `Trait` so you can box it to coerce to the trait object `Box<dyn Trait>`
   |
LL |         Box::new(Struct)
   |         +++++++++      +
error[E0308]: `if` and `else` have incompatible types
  --> $DIR/suggest-box-on-divergent-if-else-arms.rs:20:9
   |
LL |       let _ = if true {
   |  _____________-
LL | |         foo()
   | |         ----- expected because of this
LL | |     } else {
LL | |         Struct
   | |         ^^^^^^ expected `Box<dyn Trait>`, found `Struct`
LL | |     };
   | |_____- `if` and `else` have incompatible types
   |
   = note: expected struct `Box<dyn Trait>`
              found struct `Struct`
   = note: for more on the distinction between the stack and the heap, read https://doc.rust-lang.org/book/ch15-01-box.html, https://doc.rust-lang.org/rust-by-example/std/box.html, and https://doc.rust-lang.org/std/boxed/index.html
help: store this in the heap by calling `Box::new`
   |
LL |         Box::new(Struct)
   |         +++++++++      +
error[E0308]: `if` and `else` have incompatible types
  --> $DIR/suggest-box-on-divergent-if-else-arms.rs:25:9
   |
LL |   fn bar() -> impl Trait {
   |               ---------- the found opaque type
...
LL |       let _ = if true {
   |  _____________-
LL | |         Struct
   | |         ------ expected because of this
LL | |     } else {
LL | |         bar()
   | |         ^^^^^ expected `Struct`, found opaque type
LL | |     };
   | |_____- `if` and `else` have incompatible types
   |
   = note:   expected struct `Struct`
           found opaque type `impl Trait`
help: `Struct` implements `Trait` so you can box both arms and coerce to the trait object `Box<dyn Trait>`
   |
LL ~         Box::new(Struct) as Box<dyn Trait>
LL |     } else {
LL ~         Box::new(bar())
   |
error[E0308]: `if` and `else` have incompatible types
  --> $DIR/suggest-box-on-divergent-if-else-arms.rs:30:9
   |
LL |   fn bar() -> impl Trait {
   |               ---------- the expected opaque type
...
LL |       let _ = if true {
   |  _____________-
LL | |         bar()
   | |         ----- expected because of this
LL | |     } else {
LL | |         Struct
   | |         ^^^^^^ expected opaque type, found `Struct`
LL | |     };
   | |_____- `if` and `else` have incompatible types
   |
   = note: expected opaque type `impl Trait`
                   found struct `Struct`
help: `Struct` implements `Trait` so you can box both arms and coerce to the trait object `Box<dyn Trait>`
   |
LL ~         Box::new(bar()) as Box<dyn Trait>
LL |     } else {
LL ~         Box::new(Struct)
   |
```
Partially address rust-lang#102629.
    | @bors r+ rollup=never p=12 | 
    
  bors 
      added a commit
        to rust-lang-ci/rust
      that referenced
      this pull request
    
      Jan 23, 2024 
    
    
      
  
    
      
    
  
Rollup of 12 pull requests Successful merges: - rust-lang#112806 (Small code improvements in `collect_intra_doc_links.rs`) - rust-lang#119460 (coverage: Never emit improperly-ordered coverage regions) - rust-lang#119766 (Split tait and impl trait in assoc items logic) - rust-lang#120062 (llvm: change data layout bug to an error and make it trigger more) - rust-lang#120099 (linker: Refactor library linking methods in `trait Linker`) - rust-lang#120139 (Do not normalize closure signature when building `FnOnce` shim) - rust-lang#120160 (Manually implement derived `NonZero` traits.) - rust-lang#120171 (Fix assume and assert in jump threading) - rust-lang#120183 (Add `#[coverage(off)]` to closures introduced by `#[test]` and `#[bench]`) - rust-lang#120195 (add several resolution test cases) - rust-lang#120259 (Split Diagnostics for Uncommon Codepoints: Add List to Display Characters Involved) - rust-lang#120261 (Provide structured suggestion to use trait objects in some cases of `if` arm type divergence) r? `@ghost` `@rustbot` modify labels: rollup
| The job  Click to see the possible cause of the failure (guessed by this bot) | 
| 💔 Test failed - checks-actions | 
| Hmm, what is going on? | 
| #120099, maybe? | 
  
    Sign up for free
    to join this conversation on GitHub.
    Already have an account?
    Sign in to comment
  
      Labels
      
    A-testsuite
  Area: The testsuite used to check the correctness of rustc 
  
    rollup
  A PR which is a rollup 
  
    S-waiting-on-review
  Status: Awaiting review from the assignee but also interested parties. 
  
    T-bootstrap
  Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) 
  
    T-compiler
  Relevant to the compiler team, which will review and decide on the PR/issue. 
  
    T-libs
  Relevant to the library team, which will review and decide on the PR/issue. 
  
    T-rustdoc
  Relevant to the rustdoc team, which will review and decide on the PR/issue. 
  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:
collect_intra_doc_links.rs#112806 (Small code improvements incollect_intra_doc_links.rs)trait Linker#120099 (linker: Refactor library linking methods intrait Linker)FnOnceshim #120139 (Do not normalize closure signature when buildingFnOnceshim)NonZerotraits. #120160 (Manually implement derivedNonZerotraits.)#[coverage(off)]to closures introduced by#[test]and#[bench]#120183 (Add#[coverage(off)]to closures introduced by#[test]and#[bench])ifarm type divergence #120261 (Provide structured suggestion to use trait objects in some cases ofifarm type divergence)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup