Update cargo (CVE-2023-38497 fix included)
2 commits in 020651c52257052d28f6fd83fbecf5cfa1ed516c..d78bbf4bde3c6b95caca7512f537c6f9721426ff
2023-08-02 16:00:37 +0000 to 2023-08-03 12:58:25 +0000
- Fix CVE-2023-38497 for master (rust-lang/cargo#12443)
- Don't attempt to read a token from stdin if a cmdline token is provided (rust-lang/cargo#12440)
r? `@ghost`
Infer type in irrefutable slice patterns with fixed length as array
Fixes https://github.com/rust-lang/rust/issues/76342
In irrefutable slice patterns with a fixed length, we can infer the type as an array type. We now choose to prefer some implementations over others, e.g. in:
```
struct Zeroes;
const ARR: [usize; 2] = [0; 2];
const ARR2: [usize; 2] = [2; 2];
impl Into<&'static [usize; 2]> for Zeroes {
fn into(self) -> &'static [usize; 2] {
&ARR
}
}
impl Into<&'static [usize]> for Zeroes {
fn into(self) -> &'static [usize] {
&ARR2
}
}
fn main() {
let &[a, b] = Zeroes.into();
}
```
We now prefer the impl candidate `impl Into<&'static [usize; 2]> for Zeroes`, it's not entirely clear to me that this is correct, but given that the slice impl would require a type annotation anyway, this doesn't seem unreasonable.
r? `@lcnr`
Fix suggestion spans for expr from macro expansions
### Issue #112007: rustc shows expanded `writeln!` macro in code suggestion
#### Before This PR
```
help: consider using a semicolon here
|
6 | };
| +
help: you might have meant to return this value
--> C:\Users\hayle\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib/rustlib/src/rust\library\core\src\macros\mod.rs:557:9
|
55| return $dst.write_fmt($crate::format_args_nl!($($arg)*));
| ++++++ +
```
#### After This PR
```
help: consider using a semicolon here
|
LL | };
| +
help: you might have meant to return this value
|
LL | return writeln!(w, "but not here");
| ++++++ +
```
### Issue #110017: `format!` `.into()` suggestion deletes the `format` macro
#### Before This PR
```
help: call `Into::into` on this expression to convert `String` into `Box<dyn std::error::Error>`
--> /Users/eric/.rustup/toolchains/nightly-aarch64-apple-darwin/lib/rustlib/src/rust/library/alloc/src/macros.rs:121:12
|
12| res.into()
| +++++++
```
#### After This PR
```
help: call `Into::into` on this expression to convert `String` into `Box<dyn std::error::Error>`
|
LL | Err(format!("error: {x}").into())
| +++++++
```
---
Fixes#112007.
Fixes#110017.
Miscellaneous HIR typeck nits
Remove some check functions that only have one usage
Also remove `Expectation::IsLast`, which was both undocumented, and was also made redundant by my cleanup/fix in #103987😸
Temporarily eholk from review rotation
I'm going to be out for the rest of this week and then all of next week, and I generally haven't had the bandwidth to do much in the way of reviewing lately anyway. I'm going to remove myself for the review queue at least until I'm back from vacation and have some time to get a few other things in better shape.
r? `@wesleywiser`
Clarify documentation for `CStr`
* Better differentiate summaries for `from_bytes_until_nul` and `from_bytes_with_nul`
* Add some links where they may be helpful
Suggest `x build library` for a custom toolchain that fails to load `core`
Fixes#113222
The nicer suggestion for dev-channel won't be emitted if `-Z ui-testing` enabled. IMO, this is acceptable for now.
It's the same as `Delimiter`, minus the `Invisible` variant. I'm
generally in favour of using types to make impossible states
unrepresentable, but this one feels very low-value, and the conversions
between the two types are annoying and confusing.
Look at the change in `src/tools/rustfmt/src/expr.rs` for an example:
the old code converted from `MacDelimiter` to `Delimiter` and back
again, for no good reason. This suggests the author was confused about
the types.
Revert #113588 to fix bootstrap timings
This reverts #113588 which seems to have broken perf's bootstrap timings via some git issue
https://github.com/rust-lang/rust/pull/114318#issuecomment-1660807886 show a newly broken benchmark, the error at the time was
```
fatal: Path 'src/ci/channel' exists on disk, but not in 'e62323df22'.
thread 'main' panicked at 'command did not execute successfully: cd "/home/collector/rustc-perf/rust" && "git" "show" "e62323df22ecf9c163023132d17b7114f68b72e8:src/ci/channel"
expected success, got: exit status: 128', config.rs:1786:27
```
If this lands, it will reopen#101907 and annoy miri, but it could actually be an issue that would appear during the next bootstrap bump, not just rustc-perf today.
r? `@ghost`
Remove `constness` from `TraitPredicate`
Any ICEs or compiler errors created by this PR are expected and intended to be fixed in the future.
r? `@oli-obk`
cc #110395
Rollup of 5 pull requests
Successful merges:
- #114079 (Use `upvar_tys` in more places, make it return a list)
- #114166 (Add regression test for resolving `--extern libc=test.rlib`)
- #114321 (get auto traits for parallel rustc)
- #114335 (fix and extend ptr_comparison test)
- #114347 (x.py print more detailed format files and untracked files count)
r? `@ghost`
`@rustbot` modify labels: rollup
Improve `invalid_reference_casting` lint
This PR is a follow-up to https://github.com/rust-lang/rust/pull/111567 and https://github.com/rust-lang/rust/pull/113422.
This PR does multiple things:
- First it adds support for deferred de-reference, the goal is to support code like this, where the casting and de-reference are not done on the same expression
```rust
let myself = self as *const Self as *mut Self;
*myself = Self::Ready(value);
```
- Second it does not lint anymore on SB/TB UB code by only checking assignments (`=`, `+=`, ...) and creation of mutable references `&mut *`
- Thirdly it greatly improves the diagnostics in particular for cast from `&mut` to `&mut` or assignments
- ~~And lastly it renames the lint from `cast_ref_to_mut` to `invalid_reference_casting` which is more consistent with the ["rules"](https://github.com/rust-lang/rust-clippy/issues/2845) and also more consistent with what the lint checks~~ *https://github.com/rust-lang/rust/pull/113422*
This PR is best reviewed commit by commit.
r? compiler
Miri: fix error on dangling pointer inbounds offset
We used to claim that the pointer was "dereferenced", but that is just not true.
Can be reviewed commit-by-commit. The first commit is an unrelated rename that didn't seem worth splitting into its own PR.
r? `@oli-obk`
coverage: Consolidate FFI types into one module
Coverage FFI types were historically split across two modules, because some of them were needed by code in `rustc_codegen_ssa`.
Now that all of the coverage codegen code has been moved into `rustc_codegen_llvm` (#113355), it's possible to move all of the FFI types into a single module, making it easier to see all of them at once.
---
This PR only moves code and adjusts imports; there should be no functional changes.
Coverage FFI types were historically split across two modules, because some of
them were needed by code in `rustc_codegen_ssa`.
Now that all of the coverage codegen code has been moved into
`rustc_codegen_llvm` (#113355), it's possible to move all of the FFI types into
a single module, making it easier to see all of them at once.
Rollup of 6 pull requests
Successful merges:
- #114178 (Account for macros when suggesting a new let binding)
- #114199 (Don't unsize coerce infer vars in select in new solver)
- #114301 (Don't check unnecessarily that impl trait is RPIT)
- #114314 (Tweaks to `adt_sized_constraint`)
- #114322 (Fix invalid slice coercion suggestion reported in turbofish)
- #114340 ([rustc_attr][nit] Replace `filter` + `is_some` with `map_or`.)
r? `@ghost`
`@rustbot` modify labels: rollup
Fix invalid slice coercion suggestion reported in turbofish
This PR fixes the invalid slice coercion suggestion reported in turbofish and inferred generics by not emitting them.
Fixes https://github.com/rust-lang/rust/issues/110063
Don't check unnecessarily that impl trait is RPIT
We have this random `return_type_impl_trait` function to detect if a function returns an RPIT which is used in outlives suggestions, but removing it doesn't actually change any diagnostics. Let's just remove it.
Also, suppress a spurious outlives error from a ReError.
Fixes#114274
Account for macros when suggesting a new let binding
Provide a structured suggestion when the expression comes from a macro expansion:
```
error[E0716]: temporary value dropped while borrowed
--> $DIR/borrowck-let-suggestion.rs:2:17
|
LL | let mut x = vec![1].iter();
| ^^^^^^^ - temporary value is freed at the end of this statement
| |
| creates a temporary value which is freed while still in use
LL |
LL | x.use_mut();
| - borrow later used here
|
= note: this error originates in the macro `vec` (in Nightly builds, run with -Z macro-backtrace for more info)
help: consider using a `let` binding to create a longer lived value
|
LL ~ let binding = vec![1];
LL ~ let mut x = binding.iter();
|
```
