Commit 7ed00caacc improved our error reporting by including the target
function in our error messages when there is an argument count mismatch.
A simple example from the UI tests is:
```
error[E0593]: function is expected to take a single 2-tuple as argument, but it takes 0 arguments
--> $DIR/closure-arg-count.rs:32:53
|
32 | let _it = vec![1, 2, 3].into_iter().enumerate().map(foo);
| ^^^ expected function that takes a single 2-tuple as argument
...
44 | fn foo() {}
| -------- takes 0 arguments
```
However, this assumed the target span was always available. This does
not hold true if the target function is in `std` or another crate. A
simple example from #48046 is assigning `str::split` to a function type
with a different number of arguments.
Fix by removing all of the labels and suggestions related to the target
span when it's not found.
Fixes#48046
Document that associated constants prevent a trait from being made into an object
Fixes https://github.com/rust-lang/rust/issues/47952
Add a short mention of associated constants to E0038
Warn when rustc output conflicts with existing directories
When the compiled executable would conflict with a directory, display a
rustc error instead of a verbose and potentially-confusing linker
error. This is a usability improvement, and doesn’t actually change
behaviour with regards to compilation success. This addresses the
concern in #35887. Fixes#13098.
Cleanup the shim code
- We now write directly to `RETURN_PLACE` instead of creating intermediates
- `tuple_like_shim` takes an iterator (used by #47867)
- `tuple_like_shim` no longer relies on it being the first thing to create blocks, and uses relative block indexing in a cleaner way (necessary for #47867)
- All the shim builders take `dest, src` arguments instead of hardcoding RETURN_PLACE
r? @eddyb
rustc: prefer ParamEnvAnd and LayoutCx over tuples for LayoutOf.
This PR provides `tcx.layout_of(param_env.and(ty))` as the idiomatic replacement for the existing `(tcx, param_env).layout_of(ty)` and removes fragile (coherence-wise) layout-related tuple impls.
r? @nikomatsakis
Tweak presentation on lifetime trait mismatch
- On trait/impl method discrepancy, add label pointing at trait signature.
- Point only at method definition when referring to named lifetimes on lifetime mismatch.
- When the sub and sup expectations are the same, tweak the output to avoid repeated spans.
Fix#30790, CC #18759.
remove intercrate ambiguity hints
The scheme was causing overflows during coherence checking (e.g. #47139). This is sort of a temporary fix; the proper fix I think involves reworking trait selection in deeper ways.
cc @sgrif -- this *should* fix diesel
cc @qnighy -- I'd like to discuss you with alternative techniques for achieving the same end. =) Actually, it might be good to put some energy into refactoring traits first.
r? @eddyb
Add approximate suggestions for rustfix
This adds `span_approximate_suggestion()` that lets you emit a
suggestion marked as "non-machine applicable" in the JSON output. UI
users see no difference. This is for when rustc and clippy wish to
emit suggestions which will make sense to the reader (e.g. they may
have placeholders like `<type>`) but are not source-applicable, so that
rustfix/etc can ignore these.
fixes#39254
rustc: Add an option to default hidden visibility
This commit adds a new option to target specifictions to specify that symbols
should be "hidden" visibility by default in LLVM. While there are no existing
targets that take advantage of this the `wasm32-unknown-unknown` target will
soon start to use this visibility. The LLD linker currently interprets `hidden`
as "don't export this from the wasm module" which is what we want for 90% of our
functions. While the LLD linker does have a "export this symbol" argument which
is what we use for other linkers, it was also somewhat easier to do this change
instead which'll involve less arguments flying around. Additionally there's no
need for non-`hidden` visibility for most of our symbols!
This change should not immediately impact the wasm targets as-is, but rather
this is laying the foundations for soon integrating LLD as a linker for wasm
code.
Fix regression: account for trait methods in arg count mismatch error
Fixed#47706 (https://github.com/rust-lang/rust/issues/47706#issuecomment-361161495)
Original PR #47747 missed methods on trait definitions.
This edit was done in GitHub. I think I got the signature of the variant right, going by the ICE debug output and the other cases above.
This commit adds a new option to target specifictions to specify that symbols
should be "hidden" visibility by default in LLVM. While there are no existing
targets that take advantage of this the `wasm32-unknown-unknown` target will
soon start to use this visibility. The LLD linker currently interprets `hidden`
as "don't export this from the wasm module" which is what we want for 90% of our
functions. While the LLD linker does have a "export this symbol" argument which
is what we use for other linkers, it was also somewhat easier to do this change
instead which'll involve less arguments flying around. Additionally there's no
need for non-`hidden` visibility for most of our symbols!
This change should not immediately impact the wasm targets as-is, but rather
this is laying the foundations for soon integrating LLD as a linker for wasm
code.
When the compiled executable would conflict with a directory, display a
rustc error instead of a verbose and potentially-confusing linker
error. This is a usability improvement, and doesn’t actually change
behaviour with regards to compilation success. This addresses the
concern in #35887.
- On mismatch between impl and trait method, point at the trait
signature.
- Point only at the method signature instead of the whole body on
trait/impl mismatch errors.
When refering to named lifetime conflict, point only at the method's
signature span instead of the entire method.
When the expected and found sup and sub traces are the same, avoid
redundant text.
rustc: Load the `rustc_trans` crate at runtime
Building on the work of #45684 this commit updates the compiler to
unconditionally load the `rustc_trans` crate at runtime instead of linking to it
at compile time. The end goal of this work is to implement #46819 where rustc
will have multiple backends available to it to load.
This commit starts off by removing the `extern crate rustc_trans` from the
driver. This involved moving some miscellaneous functionality into the
`TransCrate` trait and also required an implementation of how to locate and load
the trans backend. This ended up being a little tricky because the sysroot isn't
always the right location (for example `--sysroot` arguments) so some extra code
was added as well to probe a directory relative to the current dll (the
rustc_driver dll).
Rustbuild has been updated accordingly as well to have a separate compilation
invocation for the `rustc_trans` crate and assembly it accordingly into the
sysroot. Finally, the distribution logic for the `rustc` package was also
updated to slurp up the trans backends folder.
A number of assorted fallout changes were included here as well to ensure tests
pass and such, and they should all be commented inline.
Building on the work of # 45684 this commit updates the compiler to
unconditionally load the `rustc_trans` crate at runtime instead of linking to it
at compile time. The end goal of this work is to implement # 46819 where rustc
will have multiple backends available to it to load.
This commit starts off by removing the `extern crate rustc_trans` from the
driver. This involved moving some miscellaneous functionality into the
`TransCrate` trait and also required an implementation of how to locate and load
the trans backend. This ended up being a little tricky because the sysroot isn't
always the right location (for example `--sysroot` arguments) so some extra code
was added as well to probe a directory relative to the current dll (the
rustc_driver dll).
Rustbuild has been updated accordingly as well to have a separate compilation
invocation for the `rustc_trans` crate and assembly it accordingly into the
sysroot. Finally, the distribution logic for the `rustc` package was also
updated to slurp up the trans backends folder.
A number of assorted fallout changes were included here as well to ensure tests
pass and such, and they should all be commented inline.
For E0277 on `for` loops, point at the "head" expression
When E0277's span points at a `for` loop, the actual issue is in the
element being iterated. Instead of pointing at the entire loop, point
only at the first line (when possible) so that the span ends in the
element for which E0277 was triggered.
