| title | tags |
|---|---|
Triage meeting 2021-05-04 |
triage-meeting |
- Meeting date: 2021-05-04
- Watch the recording
- Team members: Niko, Josh, Scott, Taylor, Felix
- Others: simulacrum
- Action item scribe: simulacrum
- Note-taker: nikomatsakis
- No pending proposals this time.
- Planning meeting tomorrow
Link: #86
- No progress, Niko still planning to do a bit of a write-up. Probably won't happen for a week or two.
Link: rust-lang/rfcs#3016
- Existing action item reminder: Felix to merge const-ub RFC rust-lang/rfcs#3016
"fn() -> Out is a valid type for unsized types Out, and it implements FnOnce<(), Output = Out>" rust#82633
Link: rust-lang/rust#82633
- Niko: need to follow up here!
- Niko to schedule a time to chat about this and decide what to do
Link: rust-lang/rust#84366
- Niko: Have a PR to review with a fix.
"Functions, closures, and HRTB-trait-objects can implement traits such that validity of associated types is never checked." rust#84533
Link: rust-lang/rust#84533
- Niko have to decide how to assess prioritization of this overall.
"HRTBs are unsound: HRTB on subtrait provides HTRB on supertrait with weaker implied bounds." rust#84591
Link: rust-lang/rust#84591
- Niko have to decide how to assess prioritization of this overall.
No nominated items this time.
Link: rust-lang/rust#51999
Unchecked action items:
-
2021-04-27: ALL to review panic in consts stabilization rust-lang/rust#51999
-
2021-04-27: Niko to move panic in consts stabilization to its own thread rust-lang/rust#51999
-
Nobody has looked closely into it yet
-
Action item: scottmcm to read into it and propose FCP if it seems appropriate
Link: rust-lang/rust#83918
- We requested this
- Stabilization writeup
- scottmcm proposed fcp merge
- Action item for folks: check your boxes
Link: rust-lang/rust#84701
- Niko: I plan to fcp merge here
fn foo<'a, 'b>(...) -> impl Trait<'a, 'b> { .. }
Complication, the solver will still have trouble with impl Trait in let binding position (but that's true regardless of what we do here):
trait Foo<'_> { }
impl Foo<'_> for &u32 { }
fn bar() {
let x: impl Foo<'_> = &44; // let's call the region variable for `'_` `'1`
}
Clarification:
- the
R member of ['a, 'b]constraint is an internal thing and not syntax users can write
// if you consider `impl Trait<'a, 'b>` as shorthand for
type FooReturn<'a, 'b> = ...; // <-- you want something you could type here
- Question (josh): Does this help us with
impl Traitin traits (and thusasync fnin traits)? - Niko: Yes, that's why I'm doing it.
- project board tracking the steps for
async fnin traits- note that the columns here represent 'milestones' and the contents are things that block those milestones
Link: rust-lang/rust#84039
- Context: we have requested that we get a chance to review uplift of clippy lints to rustc.
- Lint flags when you use the wrong ordering constant for particular atomic operations.
- Would be nice if this were a hard error! But in lieu of that, a lint is good.
- scottmcm: it'd be nice if there were some kind of attribute so that we could drive this lint more generically
- if this was some kind of language feature...
- Example: dedicated lint for Iterator::step_by to prevent passing 0
- mark: maybe if these functions were const fn...?
- niko: seems related to simd, formal verification preconditions
- Josh FCP'd, so check your boxes
- Josh: it'd be nice to have ability to break out a 'prefix' (with the panic checks etc) that can be inlined and potentially eliminated; similar to generic functions that are only generic so they can invoke
let x = x.into()and similar.
Link: rust-lang/rust#84045
- Proposes to upgrade the warning on float literals in patterns to deny
- Motivation for the warning: NaN and the general question of what constants in matches mean
- This is in the future-compatibility: the future-incompat work in cargo has not made progress yet, but we were blocking on that
- Josh: I feel this could be deny, but I'd hesitate to make it a hard error in the future (which future-incompat implies?)
- Niko: I would like to settle the story around structural equality.
- Scott: I feel like this should stay a warning until we have a plan
- Niko: I generally agree, I do think that we'll wind up with a place where matching on constants just isn't equivalent to
==at this point - Josh: But even if we don't know our plan, do we know enough to know how floats should behave?
- Niko: the main question was what to do with structs; this is a leaf case, so we can ultimately define it either way, and right now the stable behavior is compatible with
== - Scott: What happens with range patterns?
- Answer: warning
- Josh: Wouldn't range patterns be (more often) the kind of code you want to write?
- Scott: Depends, the exactness of the boundary can still be an issue
- Josh: can we summarize the open questions on the issue, and in particular the question of range patterns and the ultimate path going forward?
- In particular, we don't need answers to all the questions but we may need the answers to some to move forward.
- The author of the PR felt that range patterns are equally risky, since the edge-points of the range are equally fuzzy.
- Niko: volunteers to write up a proposal and run it by const generics working group to double check his reasoning
// Test case: outputs b
fn main() {
let x = std::f64::NAN;
match x {
std::f64::NAN => println!("a"),
_ => println!("b"),
}
}
// Generates a warning:
fn main() {
let x = 1.5;
match x {
1.0 ..= 2.0 => println!("a"),
_ => println!("b"),
}
}
warning: floating-point types cannot be used in patterns
--> src/main.rs:5:9
|
5 | 1.0 ..= 2.0 => println!("a"),
| ^^^
|
= note: `#[warn(illegal_floating_point_literal_pattern)]` on by default
= warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
= note: for more information, see issue #41620 <https://github.com/rust-lang/rust/issues/41620>
Link: rust-lang/rust#79850
- Makes the use of the
todo!macro suppress unused variable warnings - Josh would not want this unless
todo!itself generates some warning, Scott seconds - Niko: I do feel there's a problem with rustc warning a lot as you prototype code, but this narrow take on the problem doesn't seem like enough to me. For example, dead-code lint is much more common for me.
- Scott: Yeah, I'll often
#![cfg_attr(test, allow(dead_code))]or something because of this.
- Scott: Yeah, I'll often
- Mark: what annoys me the most is that I have to scroll up to find the error because of walls of warnings.
- Josh: I tend to like that early stage, "code till all the warnings are gone"
- Niko: Remember
#[expect]? whatever happened to that. This is what I usually want: a way to say "I know this is wrong but I want to know if I accidentally fix it" - Niko to find expect and then FCP close with that suggestion
Link: rust-lang/rust#81789
- Have discussed numerous times, latest summary
- Precise behavior of PR:
- The
invalid_ptr_to_int_castlint triggers if a pointer is cast to any integer type other thanusizeoru64, since doing so is often a bug.
- The
- Question at hand:
- Pr aims to address "I accidentally wrote non-portable code by casting a pointer to u32. Example: ptr as u32 when I wanted to store pointers in an integer, possibly ptr as u64."
- Doesn't necessarily address the original issue, but potentially makes sense.
- Primary concern: portability?
- False warnings: 32-bit (or less) targets
- False allows: >64-bit targets
- Primary concern: portability?
- Niko's assertion:
- This does't really solve the "casting function to integer" problem except in some cases (doesn't work for
usize::max()) - But seems useful regardless
- This does't really solve the "casting function to integer" problem except in some cases (doesn't work for
- Scott: can we do the lint but remove the 'fixes', so that we can tune it as necessary?
- Niko: we do try to encourage portability by default (e.g., across OSs), this would mean that people targeting 32 bit platforms would have to allow it
- Mark: or they could write code more carefully, e.g., using
usize - Also, the crater run has the following false warning:
[INFO] [stdout] error: casting pointer to `isize`
[INFO] [stdout] --> ndarray-sprrowlii/src/data_traits.rs:331:14
[INFO] [stdout] |
[INFO] [stdout] 331 | (ptr.as_ptr() as isize - other.as_ptr() as isize) / mem::size_of::<A>() as isize
[INFO] [stdout] | ^^^^^^^^^^^^^^^^^^^^^ help: to cast to `isize`, cast to `usize` first: `ptr.as_ptr() as usize as isize`
[INFO] [stdout] |
[INFO] [stdout] = help: pointers should only be cast to `usize` or `u64`
- Josh: reasonable if you are going to subtract it
- Scott: you've not lost information
- Josh: Proposed meeting consensus...
- remove the Fixes label
- do not warn for
isizeandi64either
- ...but cramertj is not here.
- Scott (at least) would like an add'l lint (not part of this PR) that would more aggressively lint on casting function items to any integral type, to target the original issue more squarely
* recommended path: cast the fn item to a
fn()type first i64::max as u64<-- lint on this, suggestingi64::max as fn(_)->_ as u64.
Link: rust-lang/rust#84364
This makes it possible to use
inline_const(#76001) andlet_chains(#53667) inside macros'exprpatterns in a future edition by bifurcating theexprnonterminal in a similar way topat2021to remove some backwards compatibility exceptions that disallowconst/letat the beginning of anexprmatch.
- More detailed writeup
- TL;DR: The full set of expressions have diverged somewhat
Link: rust-lang/rust#84414
- Proposal by dtolnay to support
struct Foo {
#![bar]
}
Link: rust-lang/rust#84879