Our implementation ends up changing the `PatKind::Range` variant in the
AST to take a `Spanned<RangeEnd>` instead of just a `RangeEnd`, because
the alternative would be to try to infer the span of the range operator
from the spans of the start and end subexpressions, which is both
hideous and nontrivial to get right (whereas getting the change to the
AST right was a simple game of type tennis).
This is concerning #51043.
Remove unnecessary stat64 pointer casts
In effect, these just casted `&mut stat64` to `*mut stat64`, twice.
That's harmless, but it masked a problem when this was copied to new
code calling `fstatat`, which takes a pointer to `struct stat`. That
will be fixed by #51785, but let's remove the unnecessary casts here
too.
Update broken rustc-guide links
Recently, there has been some rearrangement of the content in the Rustc
Guide, and this commit changes the urls the match the updated guide.
New safe associated functions for PinMut
- Add safe `get_mut` and `map`
- Rename unsafe equivalents to `get_mut_unchecked` and `map_unchecked`
The discussion about this starts [in this comment](https://github.com/rust-lang/rust/issues/49150#issuecomment-399604573) on the tracking issue.
Link panic and compile_error docs
This adds documentation links between `panic!()` and `compile_error!()` as per #47275, which points out that they’re similar. It also adds a sentence to the `compile_error()` docs I thought could be added.
Obligation forest cleanup
While looking at this code I was scratching my head about whether a node could appear in both `parent` and `dependents`. Turns out it can, but it's not useful to do so, so this PR cleans things up so it's no longer possible.
Fix possibly endless loop in ReadDir iterator
Certain directories in `/proc` can cause the `ReadDir` iterator to loop indefinitely. We get an error code (22) when calling libc's `readdir_r` on these directories, but `entry_ptr` is `NULL` at the same time, signalling the end of the directory stream.
This change introduces an internal state to the iterator such that the `Some(Err(..))` value will only be returned once when calling `next`. Subsequent calls will return `None`.
fixes#50619
`Self` in where clauses may not be object safe
Needs crater, virtually certain to cause regressions.
In #50781 it was discovered that our object safety rules are not sound because we allow `Self` in where clauses without restrain. This PR is a direct fix to the rules so that we disallow methods with unsound where clauses.
This currently uses hard error to measure impact, but we will want to downgrade it to a future compat error.
Part of #50781.
r? @nikomatsakis
In effect, these just casted `&mut stat64` to `*mut stat64`, twice.
That's harmless, but it masked a problem when this was copied to new
code calling `fstatat`, which takes a pointer to `struct stat`. That
will be fixed by #51785, but let's remove the unnecessary casts here
too.
build: add llvm-tools to manifest
This commit expands on a previous commit to build llvm-tools as a rustup component. It causes the llvm-tools component to be built if the extended step is active. It also adds llvm-tools to the build manifest so rustup can find it.
I tested this as far as I could, but had to hack `build-manifest/src/main.rs` a bit as it is not supported on MacOS. The main change I am not sure about is this line:
```rust
self.package("llvm-tools", &mut manifest.pkg, TARGETS);
```
There are numerous calls to `self.package()`, and I'm not sure if `TARGETS`, `HOSTS`, or `["*"]` is appropriate for llvm-tools.
Otherwise I mostly copied the example set by `rustfmt-preview`.
three diagnostics upgrades
* reword `...` expression syntax error to not imply that you should use it in patterns either (#51043) and make it a structured suggestion
* shorten the top-line message for the trivial-casts lint by tucking the advisory sentence into a help note
* structured suggestion for pattern-named-the-same-as-variant warning
r? @oli-obk
This is virtually certain to cause regressions, needs crater.
In #50781 it was discovered that our object safety rules are not sound because we allow `Self` in where clauses without restrain. This PR is a direct fix to the rules so that we disallow methods with unsound where clauses.
This currently uses hard error to measure impact, but we will want to downgrade it to a future compat error.
Fixes#50781.
r? @nikomatsakis
Prohibit `global_allocator` in submodules
Background: #44113 is caused by weird interactions with hygiene. Hygiene is hard. After a lot of playing around, we decided that the best path forward would be to prohibit `global_allocator`s from being in submodules for now. When somebody gets it working, we can re-enable it.
This PR contains the following
- Some hygiene "fixes" -- things I suspect are the correct thing to do that will make life easier in the future. This includes using call_site hygiene for the generated module and passing the correct crate name to the expansion config.
- Comments and minor formatting fixes
- Some debugging code
- Code to prohibit `global_allocator` in submodules
- Test checking that the proper error occurs.
cc #44113#49320#51241
r? @alexcrichton
- we need to figure out hygiene first
- change the test to check that the prohibition works with a good error
msg
- leaves some comments and debugging code
- leaves some of our supposed fixes
The top level message shouldn't be too long; the
replaced-by-coercion/temporary-variable advice can live in a note. Also,
don't mention type ascription when it's not actually available as a real
thing. (The current state of discussion on the type ascription tracking
issue #23416 makes one rather suspect it will never be a stable thing in
its current form, but that's not for us to adjudicate in this commit.)
While we're here, yank out the differentiating parts of the
numeric/other conditional and only have one codepath emitting the
diagnostic.
Now that `..=` inclusive ranges are stabilized, people probably
shouldn't be using `...` even in patterns, even if it's still legal
there (see #51043). To avoid drawing attention to `...` being a real
thing, let's reword this message to just say "unexpected token" rather
"cannot be used in expressions".
