- 
                Notifications
    You must be signed in to change notification settings 
- Fork 13.9k
Rolling up PRs in the queue #13443
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
            
            Rolling up PRs in the queue #13443
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
    
  
  
    
    This enables
    assert_eq!(foo.collect::<Vec<...>>().as_slice(), &[1,2,3,4]);
to work, by extending the lifetime of the .as_slice() rvalue.
    …richton collections: replace all ~[T] with Vec<T>.
…ons. This commit makes sure that code inlined from other functions isn't assigned the source position of the call site, since this leads to undesired behavior when setting line breakpoints (issue rust-lang#12886)
An optimization for sharing the type metadata of generic enum discriminators between monomorphized instances (fixes issue rust-lang#12840)
Fixes issue rust-lang#13213, that is linker errors when the inlined static has been optimized out of the exporting crate.
It suggested adding a semicolon instead of the new syntax using an exclamation mark.
These are all private uses of ~[], so can easily & non-controversially be replaced with Vec.
Replacing `~[]`. This also makes the `walk_dir` iterator use a `Vec` internally.
Some straggling instances of `~[]` across a few different libs. Also, remove some public ones from workcache.
This is supposedly undefined behavior now that Unsafe exists, so we'll use Cell instead.
Signed-off-by: OGINO Masanori <[email protected]>
I think that the test case from this issue has become out of date with resolve changes in the past 9 months, and it's not entirely clear to me what the original bug was. Regardless, it seems like tricky resolve behavior, so tests were added to make sure things resolved correctly and warnings were correctly reported. Closes rust-lang#7663
Otherwise it will prohibit `make compiler-docs` on Windows.
For the full library and compiler docs, the size of `search-index.js` decreases by 13% (18.5% after gzip -9) which is a substantial gain.
Concerns have been raised about using absolute rpaths in rust-lang#11746, and this is the first step towards not relying on rpaths at all. The only current use case for an absolute rpath is when a non-installed rust builds an executable that then moves from is built location. The relative rpath back to libstd and absolute rpath to the installation directory still remain (CFG_PREFIX). Closes rust-lang#11746 Rebasing of rust-lang#12754
This library no longer exists, there's no reason for this rpath to exist any more.
This is required in rustc to resolve symlinks for utilities such as the sysroot and the rpath values which are encoded into binaries.
When calculating the sysroot, it's more accurate to use realpath() rather than just one readlink() to account for any intermediate symlinks that the rustc binary resolves itself to. For rpath, realpath() is necessary because the rpath must dictate a relative rpath from the destination back to the originally linked library, which works more robustly if there are no symlinks involved. Concretely, any binary generated on OSX into $TMPDIR requires an absolute rpath because the temporary directory is behind a symlink with one layer of indirection. This symlink causes all relative rpaths to fail to resolve. cc rust-lang#11734 cc rust-lang#11857
…n and updated associated variable and function names.
Resolve is currently erroneously allowing imports through private `use`
statements in some circumstances, even across module boundaries. For example,
this code compiles successfully today:
    use std::c_str;
    mod test {
        use c_str::CString;
    }
This should not be allowed because it was explicitly decided that private `use`
statements are purely bringing local names into scope, they are not
participating further in name resolution.
As a consequence of this patch, this code, while valid today, is now invalid:
    mod test {
        use std::c_str;
        unsafe fn foo() {
            ::test::c_str::CString::new(0 as *u8, false);
        }
    }
While plausibly acceptable, I found it to be more consistent if private imports
were only considered candidates to resolve the first component in a path, and no
others.
Closes rust-lang#12612
    Previously resolve was checking the "import resolution" for whether an import had succeeded or not, but this was the same structure filled in by a previous import if a name is shadowed. Instead, this alters resolve to consult the local resolve state (as opposed to the shared one) to test whether an import succeeded or not. Closes rust-lang#13404
Previously, a private use statement would shadow a public use statement, all of a sudden publicly exporting the privately used item. The correct behavior here is to only shadow the use for the module in question, but for now it just reverts the entire name to private so the pub use doesn't have much effect. The behavior isn't exactly what we want, but this no longer has backwards compatibility hazards.
    
  bors 
      added a commit
      that referenced
      this pull request
    
      Apr 10, 2014 
    
    
      
  
    
      
    
  
Closes #13441 (debuginfo: Fixes and improvements for #12840, #12886, and #13213) Closes #13433 (Remove references to @trait from a compiler error message) Closes #13430 (Fix outdated lint warning about inner attribute) Closes #13425 (Remove a pile of (mainly) internal `~[]` uses) Closes #13419 (Stop using transmute_mut in RefCell) Closes #13417 (Remove an unnecessary file `src/libnative/io/p`.) Closes #13409 (Closing assorted resolve bugs) Closes #13406 (Generalized the pretty-print entry points to support `-o <file>`.) Closes #13403 (test: Add a test for #7663) Closes #13402 (rustdoc: Prune the paths that do not appear in the index.) Closes #13396 (rustc: Remove absolute rpaths) Closes #13371 (Rename ast::Purity and ast::Impure Function. Closes #7287) Closes #13350 (collections: replace all ~[T] with Vec<T>.)
  This was referenced Apr 12, 2014 
      
    
  flip1995 
      pushed a commit
        to flip1995/rust
      that referenced
      this pull request
    
      Oct 3, 2024 
    
    
      
  
    
      
    
  
…, r=xFrednet
Simplify negative `Option::{is_some_and,is_none_or}`
Closes rust-lang#13436.
Improved based on the existing lint `nonminimal_bool`, since there is already handling of similar methods `Option::{is_some,is_none}` and `Result::{is_ok,is_err}`, and there is a lot of reusable code.
When `is_some_and` or `is_none_or` have a negation, we invert it into another method by removing the Not sign and inverting the expression in the closure.
For the case where the closure block has statements, currently no simplification is implemented. (Should we do it?)
```rust
// Currently will not simplify this
_ = !opt.is_some_and(|x| {
    let complex_block = 100;
    x == complex_block
});
```
changelog: [`nonminimal_bool`]: Simplify negative `Option::{is_some_and,is_none_or}`
    
  
    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.
  
    
  
    
Closes #13441 (debuginfo: Fixes and improvements for #12840, #12886, and #13213)
Closes #13433 (Remove references to @trait from a compiler error message)
Closes #13430 (Fix outdated lint warning about inner attribute)
Closes #13425 (Remove a pile of (mainly) internal
~[]uses)Closes #13419 (Stop using transmute_mut in RefCell)
Closes #13417 (Remove an unnecessary file
src/libnative/io/p.)Closes #13409 (Closing assorted resolve bugs)
Closes #13406 (Generalized the pretty-print entry points to support
-o <file>.)Closes #13403 (test: Add a test for #7663)
Closes #13402 (rustdoc: Prune the paths that do not appear in the index.)
Closes #13396 (rustc: Remove absolute rpaths)
Closes #13371 (Rename ast::Purity and ast::Impure Function. Closes #7287)
Closes #13350 (collections: replace all ~[T] with Vec.)