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
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
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:
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.
typeck: Fix ICE with struct update syntax
If check_expr_struct_fields fails, do not continue to record update.
If we continue to record update, the struct may cause us to ICE later
on indexing a field that may or may not exist.
Fixes: #50618
rustc: leave space for fields of uninhabited types to allow partial initialization.
Fixes#49298 by only collapsing uninhabited enum variants, and only if they only have ZST fields.
Fixes#50442 incidentally (@nox's optimization didn't take into account uninhabited variants).
Better error reporting in Copy derive
In Copy derive, report all fulfillment erros when present and do not report errors for types tainted with `TyErr`. Also report all fields which are not Copy rather than just the first.
Also refactored `fn fully_normalize`, removing the not very useful helper function along with a FIXME to the closed issue #26721 that looks out of context now.
Fixes#50480
r? @estebank
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
In Copy derive, report all fulfillment erros when present and do not
report errors for types tainted with `TyErr`. Also report all fields
which are not Copy rather than just the first.
Also refactored `fn fully_normalize`, removing the not very useful
helper function along with a FIXME to the closed issue #26721 that's
looks out of context now.
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!
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
don't make crazy suggestion for unreachable braced pub-use
The Higher Intermediate Representation doesn't have spans for visibility
keywords, so we were assuming that the first whitespace-delimited token
in the item span was the `pub` to be weakened. This doesn't work for
brace-grouped `use`s, which get lowered as if they were several
individual `use` statements, but with spans that only cover the braced
path-segments. Constructing a correct suggestion here presents some
challenges—until someone works those out, we can at least protect the
dignity of our compiler by not offering any suggestion at all for `use` items.
This resolves#50455 (but again, it would be desirable in the future to
make a correct suggestion instead of copping out like this).
r? @Manishearth
If check_expr_struct_fields fails, do not continue to record update.
If we continue to record update, the struct may cause us to ICE later
on indexing a field that may or may not exist.
added missing implementation hint
Fixes [#50151](https://github.com/rust-lang/rust/issues/50151).
Actually, i don't know, should following code
`let x = |ref x: isize| { x += 1; };`
emit
`note: an implementation of std::ops::AddAssign might be missing for &isize`
or
`note: this is a reference to a type that + can be applied to; you need to dereference this variable once for this operation to work`
or both
Use the correct crt*.o files when linking musl targets.
This is supposed to support optionally using the system copy of musl
libc instead of the included one if supported. This currently only
affects the start files, which is enough to allow building rustc on musl
targets.
Most of the changes are analogous to crt-static.
Excluding the start files is something musl based distributions usually patch into their copy of rustc:
- eb064c8/community/rust/musl-fix-linux_musl_base.patch
- 77400fc/srcpkgs/rust/patches/link-musl-dynamically.patch
For third-party distributions that not yet carry those patches it would be nice if it was supported without the need to patch upstream sources.
## Reasons
### What breaks?
Some start files were missed when originally writing the logic to swap in musl start files (gcc comes with its own start files, which are suppressed by -nostdlib, but not manually included later on). This caused #36710, which also affects rustc with the internal llvm copy or any other system libraries that need crtbegin/crtend.
### How is it fixed?
The system linker already has all the logic to decide which start files to include, so we can just defer to it (except of course if it doesn't target musl).
### Why is it optional?
In #40113 it was first tried to remove the start files, which broke compiling musl-targeting static binaries with a glibc-targeting compiler. This is why it eventually landed without removing the start files. Being an option side-steps the issue.
### Why are the start files still installed?
This has the nice side-effect, that the produced rust-std-* binaries can still be used by on a glibc-targeting system with a rustc built against glibc.
## Does it work?
With the following build script (using [musl-cross-make](https://github.com/richfelker/musl-cross-make)): https://shadowice.org/~mixi/rust-musl/build.sh, I was able to cross-compile a musl-host musl-targeting rustc on a glibc-based system. The resulting binaries are at https://shadowice.org/~mixi/rust-musl/binaries/. This also requires #50103 and #50104 (which are also applied to the branch the build script uses).
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.
The Higher Intermediate Representation doesn't have spans for visibility
keywords, so we were assuming that the first whitespace-delimited token
in the item span was the `pub` to be weakened. This doesn't work for
brace-grouped `use`s, which get lowered as if they were several
individual `use` statements, but with spans that only cover the braced
path-segments. Constructing a correct suggestion here presents some
challenges—until someone works those out, we can at least protect the
dignity of our compiler marking the suggestion for `use` items as
potentially incorrect.
This resolves#50455 (but again, it would be desirable in the future to
make a correct suggestion instead of copping out like this).
Improve single-use and zero-use lifetime lints
The code now correctly identifies *when* to lint -- or more correctly, anyhow -- but it doesn't yet offer suggestions for how to fix.
(I just remembered when writing this I had meant to go back over some of these cases around e.g. impl Trait and double check that everything is right...)
cc #44752
r? @cramertj
