Don't inject clippy into the rls anymore
r? @kennytm
sorry about breaking nightlies.
The issue is that the `[patch.crates-io]` doesn't work if the versions differ. So every time we update clippy, we can only update it to the verison that rls is depending on.
I'm disabling the injection of clippy into rls for now. I'm not sure how to do this properly. We could
* add a version check, so rls only builds clippy if its dependency clippy is the same as the submodule clippy
* do something crazy like auto-patching the Cargo.toml of the rls tool repo to just use a path dependency on clippy
* build crates-io clippy instead of submodule clippy and gate clippy injection on that
* that's somewhat automatic, and is essentially what is necessary right now, but done manually
* make clippy 0.1.* instead of 0.0.* and update patch versions for nightly updates and minor version updates for `clippy_lints` api changes.
* not sure how semver-great this is
Improve eager type resolution error message
This PR improves the span of eager resolution type errors referring to indexing and field access to use the base span rather than the whole expression.
Also a "note: type must be known at this point" is added where in the past we emitted the "type must be known at this context" error, so that early failures can be differentiated and will hopefully be less surprising.
Fixes#50692 (or at least does the best we can for the moment)
r? @estebank
Migrate the toolstate update bot to rust-highfive
Rationale: Only members of the rust-lang organization can mention its teams. That means #50434 has no effect if we are still using @kennytm-githubbot.
Rewrite docs for `std::ptr`
This PR attempts to resolve#29371.
This is a fairly major rewrite of the `std::ptr` docs, and deserves a fair bit of scrutiny. It adds links to the GNU libc docs for various instrinsics, adds internal links to types and functions referenced in the docs, adds new, more complex examples for many functions, and introduces a common template for discussing unsafety of functions in `std::ptr`.
All functions in `std::ptr` (with the exception of `ptr::eq`) are unsafe because they either read from or write to a raw pointer. The "Safety" section now informs that the function is unsafe because it dereferences a raw pointer and requires that any pointer to be read by the function points to "a valid vaue of type `T`".
Additionally, each function imposes some subset of the following conditions on its arguments.
* The pointer points to valid memory.
* The pointer points to initialized memory.
* The pointer is properly aligned.
These requirements are discussed in the "Undefined Behavior" section along with the consequences of using functions that perform bitwise copies without requiring `T: Copy`. I don't love my new descriptions of the consequences of making such copies. Perhaps the old ones were good enough?
Some issues which still need to be addressed before this is merged:
- [ ] The new docs assert that `drop_in_place` is equivalent to calling `read` and discarding the value. Is this correct?
- [ ] Do `write_bytes` and `swap_nonoverlapping` require properly aligned pointers?
- [ ] The new example for `drop_in_place` is a lackluster.
- [ ] Should these docs rigorously define what `valid` memory is? Or should is that the job of the reference? Should we link to the reference?
- [ ] Is it correct to require that pointers that will be read from refer to "valid values of type `T`"?
- [x] I can't imagine ever using `{read,write}_volatile` with non-`Copy` types. Should I just link to {read,write} and say that the same issues with non-`Copy` types apply?
- [x] `write_volatile` doesn't link back to `read_volatile`.
- [ ] Update docs for the unstable [`swap_nonoverlapping`](https://github.com/rust-lang/rust/issues/42818)
- [ ] Update docs for the unstable [unsafe pointer methods RFC](https://github.com/rust-lang/rfcs/pull/1966)
Looking forward to your feedback.
r? @steveklabnik
Ensure derive(PartialOrd) is no longer accidentally exponential
Previously, two comparison operations would be generated for each field, each of which could delegate to another derived PartialOrd. Now we use ordering and optional chaining to ensure each pair of fields is only compared once, addressing https://github.com/rust-lang/rust/issues/49650#issuecomment-379467572.
Closes#49505.
r? @Manishearth (sorry for changing it again so soon!)
Close#50755
typeck: Save the index of private fields
Save the index of all fields regardless of their visibility. Problems
could occur later when attempting to index fields in error recovery if
they are not inserted.
Fixes: #50493
update libcompiler_builtins
let's OpenBSD to use libcompiler_rt.a from system library. it unbreaks
the build from source on OpenBSD.
see https://github.com/rust-lang-nursery/compiler-builtins/pull/241 for related PR
note this PR brings some other changes (on `floatdisf`/`floatundisf`) with compiler-builtins update.
r? @alexcrichton
Fix self referential impl Trait substitutions
A high impact bug because a lot of common traits use a `Self` substitution by default. Should be backported to beta.
There was a check for this which wasn't catching all cases, it was made more robust.
Fixes#49376Fixes#50626
r? @petrochenkov
Save the index of all fields regardless of their visibility. Problems
could occur later when attempting to index fields in error recovery if
they are not inserted.
This PR improves the span of eager resolution type errors referring to indexing and field access to use the base span rather than the whole expression.
Also a note "Type must be known at this point." is added to where we at some point in the past emitted the "type must be known at this context" error, so that early failures can be differentiated and will hopefully be less surprising.
Fixes#50692 (or at least does the best we can for the moment)
r? @estebank
Rollup of 8 pull requests
Successful merges:
- #50624 (fs::write: Add example writing a &str)
- #50634 (Do not silently truncate offsets for `read_at`/`write_at` on emscripten)
- #50644 (AppVeyor: Read back trace from crash dump on failure.)
- #50661 (Ignore non .rs files for tidy libcoretest)
- #50663 (rustc: Allow an edition's feature on that edition)
- #50667 (rustc: Only suggest deleting `extern crate` if it works)
- #50670 (rustc: Include semicolon when removing `extern crate`)
- #50678 (Update openbsd targets)
Failed merges:
Update openbsd targets
- add a new target `aarch64-unknown-openbsd`
- update `i686-unknown-openbsd` to use lld with clang, in order to correctly link binaries with `i128`
rustc: Include semicolon when removing `extern crate`
Currently the lint for removing `extern crate` suggests removing `extern crate`
most of the time, but the rest of the time it suggest replacing it with `use
crate_name`. Unfortunately though when spliced into the original code you're
replacing
extern crate foo;
with
use foo
which is syntactically invalid! This commit ensure that the trailing semicolon
is included in rustc's suggestion to ensure that the code continues to compile
afterwards.
rustc: Only suggest deleting `extern crate` if it works
This commit updates one of the edition lints to only suggest deleting `extern
crate` if it actually works. Otherwise this can yield some confusing behavior
with rustfix specifically where if you accidentally deny the `rust_2018_idioms`
lint in the 2015 edition it's suggesting features that don't work!
rustc: Allow an edition's feature on that edition
This commit fixes a hard error where the `#![feature(rust_2018_preview)]`
feature was forbidden to be mentioned when the `--edition 2018` flag was passed.
This instead silently accepts that feature gate despite it not being necessary.
It's intended that this will help ease the transition into the 2018 edition as
users will, for the time being, start off with the `rust_2018_preview` feature
and no longer immediately need to remove it.
Closes#50662
Ignore non .rs files for tidy libcoretest
Previously, any file would be read, which is both unnecessary, and causes issues if irrelevant non-Unicode files were read (e.g. `.DS_STORE`).
