Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change io_error abstraction #11957

Closed
nickdesaulniers opened this issue Jan 31, 2014 · 2 comments
Closed

Change io_error abstraction #11957

nickdesaulniers opened this issue Jan 31, 2014 · 2 comments

Comments

@nickdesaulniers
Copy link

Looking at the example for handling io_errors leaves a bad taste in my mouth. Not that I have any [helpful] suggestions, but can we simplify the APIs around IO and error handling?

@nickdesaulniers
Copy link
Author

Even the docs for read are kind of a mess.

@alexcrichton
Copy link
Member

You may be interested in #11946, we're switching to Result everywhere instead of a condition.

matthiaskrgr pushed a commit to matthiaskrgr/rust that referenced this issue Oct 11, 2022
…, r=Veykril

internal: change generic parameter order

tl;dr: This PR changes the `Substitution` for trait items and methods like so:

```rust
trait Trait<TP, const CP: usize> { // note the implicit Self as first parameter
  type Type<TC, const CC: usize>;
  fn f<TC, const CC: usize>() {}
}
impl<TP, const CP: usize> S {
  fn f<TC, const CC: usize>() {}
}
```

- before this PR: `[Self, TP, CP, TC, CC]` for each trait item, `[TP, CP, TC, CC]` for `S::f`
- after this PR: `[TC, CC, Self, TP, CP]` for each trait item, `[TC, CC, TP, CP]` for `S::f`

---

This PR "inverts" the generic parameters/arguments of an item and its parent. This is to fulfill [chalk's expectation](https://github.com/rust-lang/chalk/blob/d875af0ff196dd6430b5f5fd87a640fa5ab59d1e/chalk-solve/src/rust_ir.rs#L498-L502) on the order of generic arguments in `Substitution`s for generic associated types and it's one step forward for GATs support (hopefully). Although chalk doesn't put any constraint for other items, it feels more natural to get everything aligned than special casing GATs.

One complication is that `TyBuilder` now demands its users to pass in parent's `Substitution` upon construction unless it's obvious that the the item has no parent (e.g. an ADT never has parent). All users *should* already know the parent of the item in question, and without this, it cannot be easily reasoned about whether we're pushing the argument for the item or for its parent.

Some additional notes:
- f8f5a5e: This isn't related to the change, but I felt it's nicer.

- 78977cd: There's one major change here other than the generic param order: Default arguments are now bound by the same `Binder` as the item in question rather than a `Binder` limited to parameters they can refer to (i.e. arguments that syntactically appear before them). Now that the order of generic parameters is changed, it would be somewhat complicated to make such `Binder`s as before, and the "full" `Binder`s shouldn't be a problem because we already make sure that the default arguments don't refer to the generic arguments after them with `fallback_bound_vars()`.

- 7556f74: This is split from 4385d3d to make it easy to revert if it turns out that the GATs with const generics panic is actually not resolved with this PR. cc rust-lang#11878 rust-lang#11957
flip1995 pushed a commit to flip1995/rust that referenced this issue Jan 11, 2024
don't lint [`default_numeric_fallback`] on return and local assigned macro calls with type stated

fixes: rust-lang#11535

changelog: don't lint [`default_numeric_fallback`] on return and local assigned macro calls with type stated
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants