For enums with an aligned ZST variant, like `[T; 0]`, the niche layout
was not computing a sufficient size to be consistent with alignment. Now
we pad that size up to the alignment, and also make sure to only use the
niche variant's ABI when the size and alignment still match.
Rollup of 5 pull requests
Successful merges:
- #99311 (change maybe_body_owned_by to take local def id)
- #99862 (Improve type mismatch w/ function signatures)
- #99895 (don't call type ascription "cast")
- #99900 (remove some manual hash stable impls)
- #99903 (Add diagnostic when using public instead of pub)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Fixes a warning:
warning: llvm-wrapper/RustWrapper.cpp:159:11: warning: enumeration values 'AllocatedPointer' and 'AllocAlign' not handled in switch [-Wswitch]
warning: switch (Kind) {
warning: ^
Which was fall out from 130a1df71e.
Add diagnostic when using public instead of pub
Forwarding from https://github.com/rust-lang/rust/pull/99706
I accidentally broke something(??) in git and the commits in that PR are absolutely not what I did in that branch
Anyways, this is the PR for this now. Adding tests again in a minute.
cc `@davidtwco`
Improve type mismatch w/ function signatures
This PR makes use of `note: expected/found` (instead of labeling types in labels) in type mismatch with function signatures. Pros: it's easier to compare the signatures, cons: the error is a little more verbose now.
This is especially nice when
- The signatures differ in a small subset of parameters (same parameters are elided)
- The difference is in details, for example `isize` vs `usize` (there is a better chance that the types align)
Also this PR fixes the inconsistency in variable names in the edited code (`expected` and `found`).
A zulip thread from which this pr started: [[link]](https://rust-lang.zulipchat.com/#narrow/stream/147480-t-compiler.2Fwg-diagnostics/topic/Type.20error.20regression.3F.2E.2E.2E/near/289756602).
An example diagnostic:
<table>
<tr>
<th>this pr</th>
<th>nightly</th>
</tr>
<tr>
<td>
```text
error[E0631]: type mismatch in function arguments
--> ./t.rs:4:12
|
4 | expect(&f);
| ------ ^^ expected due to this
| |
| required by a bound introduced by this call
...
10 | fn f(_: isize, _: u8, _: Vec<u32>) {}
| ---------------------------------- found signature defined here
|
= note: expected function signature `fn(usize, _, Vec<u64>) -> _`
found function signature `fn(isize, _, Vec<u32>) -> _`
note: required because of the requirements on the impl of `Trait` for `fn(isize, u8, Vec<u32>) {f}`
--> ./t.rs:8:9
|
8 | impl<F> Trait for F where F: Fn(usize, u8, Vec<u64>) -> u8 {}
| ^^^^^ ^
= note: required for the cast from `fn(isize, u8, Vec<u32>) {f}` to the object type `dyn Trait`
```
</td>
<td>
```text
error[E0631]: type mismatch in function arguments
--> ./t.rs:4:12
|
4 | expect(&f);
| ------ ^^ expected signature of `fn(usize, u8, Vec<u64>) -> _`
| |
| required by a bound introduced by this call
...
10 | fn f(_: isize, _: u8, _: Vec<u32>) {}
| ---------------------------------- found signature of `fn(isize, u8, Vec<u32>) -> _`
|
note: required because of the requirements on the impl of `Trait` for `fn(isize, u8, Vec<u32>) {f}`
--> ./t.rs:8:9
|
8 | impl<F> Trait for F where F: Fn(usize, u8, Vec<u64>) -> u8 {}
| ^^^^^ ^
= note: required for the cast to the object type `dyn Trait`
```
</td>
</tr>
</table>
<details><summary>code</summary>
<p>
```rust
fn main() {
fn expect(_: &dyn Trait) {}
expect(&f);
}
trait Trait {}
impl<F> Trait for F where F: Fn(usize, u8, Vec<u64>) -> u8 {}
fn f(_: isize, _: u8, _: Vec<u32>) {}
```
</p>
</details>
r? `@compiler-errors`
Remove `TreeAndSpacing`.
A `TokenStream` contains a `Lrc<Vec<(TokenTree, Spacing)>>`. But this is
not quite right. `Spacing` makes sense for `TokenTree::Token`, but does
not make sense for `TokenTree::Delimited`, because a
`TokenTree::Delimited` cannot be joined with another `TokenTree`.
This commit fixes this problem, by adding `Spacing` to `TokenTree::Token`,
changing `TokenStream` to contain a `Lrc<Vec<TokenTree>>`, and removing the
`TreeAndSpacing` typedef.
The commit removes these two impls:
- `impl From<TokenTree> for TokenStream`
- `impl From<TokenTree> for TreeAndSpacing`
These were useful, but also resulted in code with many `.into()` calls
that was hard to read, particularly for anyone not highly familiar with
the relevant types. This commit makes some other changes to compensate:
- `TokenTree::token()` becomes `TokenTree::token_{alone,joint}()`.
- `TokenStream::token_{alone,joint}()` are added.
- `TokenStream::delimited` is added.
This results in things like this:
```rust
TokenTree::token(token::Semi, stmt.span).into()
```
changing to this:
```rust
TokenStream::token_alone(token::Semi, stmt.span)
```
This makes the type of the result, and its spacing, clearer.
These changes also simplifies `Cursor` and `CursorRef`, because they no longer
need to distinguish between `next` and `next_with_spacing`.
r? `@petrochenkov`
Only __rustc_proc_macro_decls_*__ and rust_metadata_* need to be
exported for proc macros to work. All other symbols only increase binary
size and have the potential to conflict with symbols from the host
compiler.
use `check_region_obligations_and_report_errors` to avoid ICEs
If we don't call `process_registered_region_obligations` before `resolve_regions_and_report_errors` then we'll ICE if we have any region obligations, and `check_region_obligations_and_report_errors` just does both of these for us in a nice convenient function.
Fixes#53475
r? types
proc_macro: use crossbeam channels for the proc_macro cross-thread bridge
This is done by having the crossbeam dependency inserted into the `proc_macro` server code from the server side, to avoid adding a dependency to `proc_macro`.
In addition, this introduces a -Z command-line option which will switch rustc to run proc-macros using this cross-thread executor. With the changes to the bridge in #98186, #98187, #98188 and #98189, the performance of the executor should be much closer to same-thread execution.
In local testing, the crossbeam executor was substantially more performant than either of the two existing `CrossThread` strategies, so they have been removed to keep things simple.
r? `@eddyb`
Rollup of 8 pull requests
Successful merges:
- #99227 (Fix thumbv4t-none-eabi frame pointer setting)
- #99518 (Let-else: break out scopes when a let-else pattern fails to match)
- #99671 (Suggest dereferencing index when trying to use a reference of usize as index)
- #99831 (Add Fuchsia platform support documentation)
- #99881 (fix ICE when computing codegen_fn_attrs on closure with non-fn parent)
- #99888 (Streamline lint checking)
- #99891 (Adjust an expr span to account for macros)
- #99904 (Cleanup html whitespace)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Adjust an expr span to account for macros
Fix this erroneous suggestion:
```
error[E0529]: expected an array or slice, found `Vec<{integer}>`
--> /home/gh-compiler-errors/test.rs:2:9
|
2 | let [..] = vec![1, 2, 3];
| ^^^^ pattern cannot match with input type `Vec<{integer}>`
|
help: consider slicing here
--> /home/gh-compiler-errors/rust2/library/alloc/src/macros.rs:50:36
|
50~ $crate::__rust_force_expr!(<[_]>::into_vec(
51+ #[rustc_box]
52+ $crate::boxed::Box::new([$($x),+])
53~ )[..])
```
Streamline lint checking
The early (AST) and late (HIR) lint checkers have a number of functions that aren't used by rustc or clippy. Might as well remove them -- it's not like there's a canonical API here, as shown by the ad hoc use of `check_foo`/`check_foo_post` combinations.
r? `@cjgillot`
fix ICE when computing codegen_fn_attrs on closure with non-fn parent
Other call sites check `has_codegen_attrs` first, so let's do that too.
Fixes#99876
Let-else: break out scopes when a let-else pattern fails to match
This PR will commit to a new behavior so that values from initializer expressions are dropped earlier when a let-else pattern fails to match.
Fix#98672.
Close#93951.
cc `@camsteffen` `@est31`
Fix thumbv4t-none-eabi frame pointer setting
The `thumb_base` profile has changed since I last remember seeing it, and now it sets the frame pointer to "always keep", which is not desired for this target. Hooking a debugger to the running program is not really done, it's preferable to have the register available for actual program use, so the default "may omit" is now set.
I thought that the target was already using "may omit" when I checked on it last month, because I forgot that the target was previously based on `thumb_base` rather than `Default::default()`. I only noticed the issue just now when creating the `armv4t-none-eabi` target (https://github.com/rust-lang/rust/pull/99226), though this PR is not in any way conditional on that one.
This is done by having the crossbeam dependency inserted into the
proc_macro server code from the server side, to avoid adding a
dependency to proc_macro.
In addition, this introduces a -Z command-line option which will switch
rustc to run proc-macros using this cross-thread executor. With the
changes to the bridge in #98186, #98187, #98188 and #98189, the
performance of the executor should be much closer to same-thread
execution.
In local testing, the crossbeam executor was substantially more
performant than either of the two existing CrossThread strategies, so
they have been removed to keep things simple.
Rollup of 8 pull requests
Successful merges:
- #99686 (add suggestion when there is a impl of external trait on pointer with wrong coherence rules)
- #99760 (doc/rustc: describe the uefi target platforms)
- #99766 (Htmldocck: Substitute the doc channel when blessing)
- #99781 (Use String::from_utf8_lossy in CStr demo)
- #99803 (Update mentions to `rustc_metadata::rmeta::Lazy`)
- #99845 (Remove `$` prefix for bash scripts in doc)
- #99850 (rustdoc: Remove more Clean trait implementations)
- #99872 (Clone the `src/llvm-project` submodule if profiling is enabled)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Update mentions to `rustc_metadata::rmeta::Lazy`
While working on https://github.com/rust-lang/rustc-dev-guide/pull/1411, I noticed there are still some mentions of `Lazy`. This updates them to `LazyValue`, `LazyArray`, or `LazyTable`.
r? ````@compiler-errors````
Signed-off-by: Yuki Okushi <jtitor@2k36.org>
add suggestion when there is a impl of external trait on pointer with wrong coherence rules
Closes https://github.com/rust-lang/rust/issues/99572
This will try to improve the node in the error message by suggesting a general solution because the solution, in this case, is application depended.
I'm not super happy regarding the code quality, but I'm happy to have feedback on it.
`@rustbot` r? `@compiler-errors`
A `TokenStream` contains a `Lrc<Vec<(TokenTree, Spacing)>>`. But this is
not quite right. `Spacing` makes sense for `TokenTree::Token`, but does
not make sense for `TokenTree::Delimited`, because a
`TokenTree::Delimited` cannot be joined with another `TokenTree`.
This commit fixes this problem, by adding `Spacing` to `TokenTree::Token`,
changing `TokenStream` to contain a `Lrc<Vec<TokenTree>>`, and removing the
`TreeAndSpacing` typedef.
The commit removes these two impls:
- `impl From<TokenTree> for TokenStream`
- `impl From<TokenTree> for TreeAndSpacing`
These were useful, but also resulted in code with many `.into()` calls
that was hard to read, particularly for anyone not highly familiar with
the relevant types. This commit makes some other changes to compensate:
- `TokenTree::token()` becomes `TokenTree::token_{alone,joint}()`.
- `TokenStream::token_{alone,joint}()` are added.
- `TokenStream::delimited` is added.
This results in things like this:
```rust
TokenTree::token(token::Semi, stmt.span).into()
```
changing to this:
```rust
TokenStream::token_alone(token::Semi, stmt.span)
```
This makes the type of the result, and its spacing, clearer.
These changes also simplifies `Cursor` and `CursorRef`, because they no longer
need to distinguish between `next` and `next_with_spacing`.
Generate correct suggestion with named arguments used positionally
Address issue #99265 by checking each positionally used argument
to see if the argument is named and adding a lint to use the name
instead. This way, when named arguments are used positionally in a
different order than their argument order, the suggested lint is
correct.
For example:
```
println!("{b} {}", a=1, b=2);
```
This will now generate the suggestion:
```
println!("{b} {a}", a=1, b=2);
```
Additionally, this check now also correctly replaces or inserts
only where the positional argument is (or would be if implicit).
Also, width and precision are replaced with their argument names
when they exists.
Since the issues were so closely related, this fix for issue #99265
also fixes issue #99266.
Fixes#99265Fixes#99266
LLVM 15 compatibility fixes
These are LLVM 15 compatibility fixes split out from #99464. There are three changes here:
* Emit elementtype attribtue for ldrex/strex intrinsics. This is requires as part of the opaque pointers migration.
* Make more tests compatible with opaque pointers. These are either new or aren't run on x86.
* Remove a test for `#[rustc_allocator]`. Since #99574 there are more requirement on the function signature. I dropped the test entirely, since we already test the effect of the attribute elsewhere.
* The main change: When a worker thread emits an error, wait for other threads to finish before unwinding the main thread and exiting. Otherwise workers may end up using globals for which destructors have already been run. This was probably never quite correct, but became an active problem with LLVM 15, because it started using global dtors in critical places, as part of ManagedStatic removal.
Fixes#99432 (and probably also #95679).
r? `@cuviper`
Prior to this fix, `-Z location-detail` provided no mechanism for
disabling all location details. This commit also adds a test case
to verify that this option continues to work as intended, and
clarifies the documentation of this option.
fix: remove fake no_dead_strip for osx
Closes https://github.com/rust-lang/rust/issues/99788
Link arg `-no_dead_strip` doesn't exist on OSX at all.
The `no_gc_sections` function was never called before export-executable-symols implementation, and `export-executable-symbols` still works, so we just remove it.
r? `@bjorn3`
Use line numbers relative to the function in mir-opt tests
As shown in #99770, the line numbers can be a big source of needless and confusing diffs. This PR adds a new flag `-Zmir-pretty-relative-line-numbers` to make them relative to the function declaration, which avoids most needless diffs from attribute changes.
`@JakobDegen` told me that there has been a zulip conversation about disabling line numbers with mixed opinions, so I'd like to get some feedback here, for this hopefully better solution.
r? rust-lang/wg-mir-opt
This avoids monomorphizing all linker code for each codegen backend and
will allow passing in extra information to the archive builder from the
codegen backend.
This initial implementation handles transmutations between types with specified layouts, except when references are involved.
Co-authored-by: Igor null <m1el.2027@gmail.com>
lint: add bad opt access internal lint
Prompted by [Zulip discussion](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/sess.2Ecrate_types.28.29.20vs.20sess.2Eopts.2Ecrate_types/near/290682847).
Some command-line options accessible through `sess.opts` are best accessed through wrapper functions on `Session`, `TyCtxt` or otherwise, rather than through field access on the option struct in the `Session`.
Adds a new lint which triggers on those options that should be accessed through a wrapper function so that this is prohibited. Options are annotated with a new attribute `rustc_lint_opt_deny_field_access` which can specify the error message (i.e. "use this other function instead") to be emitted.
A simpler alternative would be to simply rename the options in the option type so that it is clear they should not be used, however this doesn't prevent uses, just discourages them. Another alternative would be to make the option fields private, and adding accessor functions on the option types, however the wrapper functions sometimes rely on additional state from `Session` or `TyCtxt` which wouldn't be available in an function on the option type, so the accessor would simply make the field available and its use would be discouraged too.
**Leave a comment if there's an option I should add this to.**
Deeply deny fn and raw ptrs in const generics
I think this is right -- just because we wrap a fn ptr in a wrapper type does not mean we should allow it in a const parameter.
We now reject both of these in the same way:
```
#![feature(adt_const_params)]
#[derive(Eq, PartialEq)]
struct Wrapper();
fn foo<const W: Wrapper>() {}
fn foo2<const F: fn()>() {}
```
This does regress one test (`src/test/ui/consts/refs_check_const_eq-issue-88384.stderr`), but I'm not sure it should've passed in the first place.
cc: ``@b-naber`` who introduced that test^
fixes#99641
Remove let-chain close brace check.
#98633 added some checks to forbid let-expressions that aren't in a let chain. This check looks at the preceding token to determine if it is a valid let-chain position. One of those tokens it checks is the close brace `}`. However, to my understanding, it is not possible for a let chain to be preceded by a close brace. This PR removes the check to avoid any confusion.
This is a followup to the discussion at https://github.com/rust-lang/rust/pull/98633#pullrequestreview-1030962803. It wasn't clear what issues the original PR ran into, but I have run the full set of CI tests and nothing failed. I also can't conceive of a situation where this would be possible. This doesn't reject any valid code, I'm just removing it to avoid confusion to anyone looking at this code in the future.
Replace the separate AbortCodegenOnDrop guard by integrating this
functionality into OngoingCodegen (or rather, the Coordinator part
of it). This ensures that we send a CodegenAborted message and
wait for workers to finish even if the panic occurs outside
codegen_crate() (e.g. inside join_codegen()).
This requires some minor changes to the handling of CodegenAborted,
as it can now occur when the main thread is LLVMing rather than
Codegenning.
Some command-line options accessible through `sess.opts` are best
accessed through wrapper functions on `Session`, `TyCtxt` or otherwise,
rather than through field access on the option struct in the `Session`.
Adds a new lint which triggers on those options that should be accessed
through a wrapper function so that this is prohibited. Options are
annotated with a new attribute `rustc_lint_opt_deny_field_access` which
can specify the error message (i.e. "use this other function instead")
to be emitted.
A simpler alternative would be to simply rename the options in the
option type so that it is clear they should not be used, however this
doesn't prevent uses, just discourages them. Another alternative would
be to make the option fields private, and adding accessor functions on
the option types, however the wrapper functions sometimes rely on
additional state from `Session` or `TyCtxt` which wouldn't be available
in an function on the option type, so the accessor would simply make the
field available and its use would be discouraged too.
Signed-off-by: David Wood <david.wood@huawei.com>
If an internal lint uses `typeck_results` or similar queries then that
can result in rustdoc checking code that it shouldn't (e.g. from other
platforms) and emit compilation errors.
Signed-off-by: David Wood <david.wood@huawei.com>
Sync rustc_codegen_cranelift
I did a large refactoring of the intrinsics module to remove the intrinsic_match macro which is not very clear to other people. This also enables rustfmt to run on this code. While I already did a sync yesterday, I am going to do another sync again to avoid potential conflicts as those will likely be painful to resolve.
r? ``@ghost``
``@rustbot`` label +A-codegen +A-cranelift +T-compiler
Check that RPITs constrained by a recursive call in a closure are compatible
Fixes#99073
Adapts a similar visitor pattern to `find_opaque_ty_constraints` (that we use to check TAITs), but with some changes:
0. Only walk the "OnlyBody" children, instead of all items in the RPIT's defining scope
1. Only walk through the body's children if we found a constraining usage
2. Don't actually do any inference, just do a comparison and error if they're mismatched
----
r? `@oli-obk` -- you know all this impl-trait stuff best... is this the right approach? I can explain the underlying issue better if you'd like, in case that might reveal a better solution. Not sure if it's possible to gather up the closure's defining usages of the RPIT while borrowck'ing the outer function, that might be a better place to put this check...
Add a brief comment explaining why the diagnostic migration lints aren't
included in the `rustc::internal` diagnostic group.
Signed-off-by: David Wood <david.wood@huawei.com>
passes: port more of `check_attr` module
Continues from #99213.
Port more diagnostics in `rustc_passes::check_attr` to using the diagnostic derive and translation machinery.
r? `@compiler-errors`
Prefer visibility map parents that are not `doc(hidden)` first
Far simpler approach to #98876.
This only fixes the case where the parent is `doc(hidden)`, not where the child is `doc(hidden)` since I don't know how to get the attrs on the import statement given a `ModChild`... I'll try to follow up with that, but this is a good first step.
codegen: use new {re,de,}allocator annotations in llvm
This obviates the patch that teaches LLVM internals about
_rust_{re,de}alloc functions by putting annotations directly in the IR
for the optimizer.
The sole test change is required to anchor FileCheck to the body of the
`box_uninitialized` method, so it doesn't see the `allocalign` on
`__rust_alloc` and get mad about the string `alloca` showing up. Since I
was there anyway, I added some checks on the attributes to prove the
right attributes got set.
r? `@nikic`
This obviates the patch that teaches LLVM internals about
_rust_{re,de}alloc functions by putting annotations directly in the IR
for the optimizer.
The sole test change is required to anchor FileCheck to the body of the
`box_uninitialized` method, so it doesn't see the `allocalign` on
`__rust_alloc` and get mad about the string `alloca` showing up. Since I
was there anyway, I added some checks on the attributes to prove the
right attributes got set.
While we're here, we also emit allocator attributes on
__rust_alloc_zeroed. This should allow LLVM to perform more
optimizations for zeroed blocks, and probably fixes#90032. [This
comment](https://github.com/rust-lang/rust/issues/24194#issuecomment-308791157)
mentions "weird UB-like behaviour with bitvec iterators in
rustc_data_structures" so we may need to back this change out if things
go wrong.
The new test cases require LLVM 15, so we copy them into LLVM
14-supporting versions, which we can delete when we drop LLVM 14.
Rollup of 5 pull requests
Successful merges:
- #99618 (handle consts with param/infer in `const_eval_resolve` better)
- #99666 (Restore `Opaque` behavior to coherence check)
- #99692 (interpret, ptr_offset_from: refactor and test too-far-apart check)
- #99739 (Remove erroneous E0133 code from an error message.)
- #99748 (Use full type name instead of just saying `impl Trait` in "captures lifetime" error)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Use full type name instead of just saying `impl Trait` in "captures lifetime" error
I think this is very useful, especially when there's >1 `impl Trait`, and it just means passing around a bit more info that we already have access to.
Remove erroneous E0133 code from an error message.
This error message is about `derive` and `packed`, but E0133 is for
"Unsafe code was used outside of an unsafe function or block".
r? ``@estebank``
interpret, ptr_offset_from: refactor and test too-far-apart check
We didn't have any tests for the "too far apart" message, and indeed that check mostly relied on the in-bounds check and was otherwise probably not entirely correct... so I rewrote that check, and it is before the in-bounds check so we can test it separately.
Restore `Opaque` behavior to coherence check
Fixes#99663.
This broke in 84c3fcd2a0. I'm not exactly certain that adding this behavior back is necessarily correct, but at least the UI test I provided may stimulate some thoughts.
I think delaying a bug here is certainly not correct in the case of opaques -- if we want to change coherence behavior for opaques, then we should at least be emitting a new error.
r? ``@lcnr``
handle consts with param/infer in `const_eval_resolve` better
This PR addresses [this thread here](https://github.com/rust-lang/rust/pull/99449#discussion_r924141230). Was this the change you were looking for ``@lcnr?``
Interestingly, one test has begun to pass. Was that expected?
r? ``@lcnr``
Sync rustc_codegen_cranelift
This time most of the changes are bugfixes. No exciting new features to report. Thanks `@matthiaskrgr` for reporting a bunch of crashes!
r? `@ghost`
`@rustbot` label +A-codegen +A-cranelift +T-compiler
Remove reachable coverage without counters
Remove reachable coverage without counters to maintain invariant that
either there is no coverage at all or there is a live coverage counter
left that provides the function source hash.
The motivating example would be a following closure:
```rust
let f = |x: bool| {
debug_assert!(x);
};
```
Which, with span changes from #93967, with disabled debug assertions,
after the final CFG simplifications but before removal of dead blocks,
gives rise to MIR:
```rust
fn main::{closure#0}(_1: &[closure@a.rs:2:13: 2:22], _2: bool) -> () {
debug x => _2;
let mut _0: ();
bb0: {
Coverage::Expression(4294967295) = 1 - 2;
return;
}
...
}
```
Which also makes the initial instrumentation quite suspect, although
this pull request doesn't attempt to address that aspect directly.
Fixes#98833.
r? ``@wesleywiser`` ``@richkadel``
Remove some explicit `self.infcx` for `FnCtxt`, which already derefs into `InferCtxt`
The use of `self.infcx.method_on_infcx` vs `self.method_on_infcx` when `self` is a `FnCtxt` is a bit inconsistent, so I'm moving some `self.infcx` usages I found to just use autoderef
Slightly improve mismatched GAT where clause error
This makes the error reporting a bit more standardized between `where` on GATs and functions.
cc #99206 (`@BoxyUwU),` don't want to mark this as as "fixed" because they're still not perfect, but this is still an improvement IMO so I want to land it incrementally.
regarding "consider adding where clause to trait definition", we don't actually do that for methods as far as i can tell? i could file an issue to look into that maybe.
