According to http://www.musl-libc.org/download.html:
This release corrects regressions in glob() and armv4t build failure
introduced in the previous release, and includes an important bug fix
for posix_spawnp in the presence of a large PATH environment variable.
Replace empty array hack with repr(align)
As a side effect, this fixes the warning about repr(C, simd) that has been reported during x86_64 windows builds since #47111 (see also: #47103)
r? @alexcrichton
fix the doc-comment-decoration-trimming edge-case rustdoc ICE
This `horizontal_trim` function strips the leading whitespace from
doc-comments that have a left-asterisk-margin:
```
/**
* You know what I mean—
*
* comments like this!
*/
```
The index of the column of asterisks is `i`, and if trimming is deemed
possible, we slice each line from `i+1` to the end of the line. But if, in
particular, `i` was 0 _and_ there was an empty line (as in the example
given in the reporting issue), we ended up panicking trying to slice an
empty string from 0+1 (== 1).
Let's tighten our check to say that we can't trim when `i` is even the same
as the length of the line, not just when it's greater. (Any such cases
would panic trying to slice `line` from `line.len()+1`.)
Resolves#47197.
Add help message for incorrect pattern syntax
When I was getting started with rust I often made the mistake of using `||` instead of `|` to match multiple patterns and spent a long time staring at my code wondering what was wrong.
for example:
```
fn main() {
let x = 1;
match x {
1 || 2 => println!("1 or 2"),
_ => println!("Something else"),
}
}
```
If you compile this with current rustc you will see
```
error: expected one of `...`, `..=`, `..`, `=>`, `if`, or `|`, found `||`
--> test.rs:5:11
|
5 | 1 || 2 => println!("1 or 2"),
| -^^ unexpected token
| |
| expected one of `...`, `..=`, `..`, `=>`, `if`, or `|` here
error: aborting due to previous error
```
With my proposed change it will show:
```
error: unexpected token `||` after pattern
--> test.rs:5:11
|
5 | 1 || 2 => println!("1 or 2"),
| ^^
|
= help: did you mean to use `|` to specify multiple patterns instead?
error: aborting due to previous error
```
Make normalize_and_test_predicates into a query
From #44891.
I'm not real solid on how `dep_graph` stuff works, but if a node is going to have a key (again, not sure how important that is), then the key needs to be `Copy`. So since `normalize_and_test_predicates` only had one out-of-module use, I changed that call site to use a new function, `substitute_normalize_and_test_predicates` which is the query and enables having the arguments be `Copy`. Hopefully this makes sense.
r? @nikomatsakis
and/or @michaelwoerister
- Recover from struct parse error on match and point out missing match
body.
- Point at struct when finding non-identifier while parsing its fields.
- Add label to "expected identifier, found {}" error.
Provide suggestion when trying to use method on numeric literal
New output:
```
error[E0688]: can't call method `powi` on ambiguous numeric type `{float}`
--> $DIR/method-on-ambiguous-numeric-type.rs:12:17
|
12 | let x = 2.0.powi(2);
| ^^^^
help: you must specify a concrete type for this numeric value, like `f32`
|
12 | let x = 2.0_f32.powi(2);
| ^^^^^^^
```
Previous output:
```
error[E0599]: no method named `powi` found for type `{float}` in the current scope
--> src/main.rs:12:17
|
12 | let x = 2.0.powi(2);
| ^^^^
|
= help: items from traits can only be used if the trait is in scope
help: the following trait is implemented but not in scope, perhaps add a `use` for it:
|
11 | use core::num::Float;
|
```
Fix#40985.
The `#[simd]` attribute has been deprecated since c8b6d5b23cc8b2d43ece9f06252c7e98280fb8e5 back in 2015. Any nightly crates using it have had ample time to switch to `#[repr(simd)]`, and if they didn't they're likely broken by now anyway.
rustdoc: Add missing src links for generic impls on trait pages
`implementor2item` would return `None` for generic impls so instead this clones the entire `clean::Item` into the `implementors` map which simplifies some code.
Map invalid Spans to DUMMY_SP during crate metadata encoding.
This mirrors what we do for stabilizing the incr. comp. cache and is necessary for reproducible builds. For the incr. comp. cache, we *have* to do this because the encoding there cannot represent broken Spans. Metadata encoding has to be in sync with that as not to get unexpected interactions when compiling incrementally.
This should help with fixing issue https://github.com/rust-lang/rust/issues/47066.
r? @alexcrichton
ci: use a shared script to build musl
The dist-x86_64-musl, dist-various-1 and dist-i586-gnu-i686-musl builders had different scripts to build musl. This PR creates an unified script, which makes it easier to add new musl targets and update musl and libunwind (used in the musl targets).
The libunwind is update from 3.7 to 3.9 for dist-x86_64-musl and dist-i586-gnu-i686-musl (dist-various-1 already used 3.9 version).
The ref was actually always necessary.
This clarifies some incorrect thinking in the original code that might
have led to errors in the future to do with unsizing.
Previously, on a type mismatch (and if this wasn't preëmpted by a
higher-priority suggestion), we would look for argumentless methods
returning the expected type, and list them in a `help` note.
This had two major shortcomings. Firstly, a lot of the suggestions didn't
really make sense (if you used a &str where a String was expected,
`.to_ascii_uppercase()` is probably not the solution you were hoping
for). Secondly, we weren't generating suggestions from the most useful
traits!
We address the first problem with an internal
`#[rustc_conversion_suggestion]` attribute meant to mark methods that keep
the "same value" in the relevant sense, just converting the type. We
address the second problem by making `FnCtxt.probe_for_return_type` pass
the `ProbeScope::AllTraits` to `probe_op`: this would seem to be safe
because grep reveals no other callers of `probe_for_return_type`.
Also, structured suggestions are preferred (because they're pretty, but
also for RLS and friends).
Also also, we make the E0055 autoderef recursion limit error use the
one-time-diagnostics set, because we can potentially hit the limit a lot
during probing. (Without this,
test/ui/did_you_mean/recursion_limit_deref.rs would report "aborting due to
51 errors").
Unfortunately, the trait probing is still not all one would hope for: at a
minimum, we don't know how to rule out `into()` in cases where it wouldn't
actually work, and we don't know how to rule in `.to_owned()` where it
would. Issues #46459 and #46460 have been filed and are ref'd in a FIXME.
This is hoped to resolve#42929, #44672, and #45777.
