undefined reference to `timerfd_settime' #13335
Comments
|
Closing as a dupe of #13447 (it's got more tags over there), same bug though. |
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
matthiaskrgr
pushed a commit
to matthiaskrgr/rust
that referenced
this issue
Oct 11, 2022
…, r=Veykril fix: treat enum variants as generic item on their own Fixup for rust-lang#13335 It turns out I tried to merge two procedures into one utility function without noticing the incompatibility. This time I *did* run analysis-stats on the four crates and confirmed it doesn't crash and this patch doesn't cause regression.
matthiaskrgr
pushed a commit
to matthiaskrgr/rust
that referenced
this issue
Oct 11, 2022
…, r=Veykril fix: use `BoundVar`s from current generic scope Fixup for rust-lang#13335, addresses rust-lang/rust-analyzer#13339 (comment) Before the change in generic parameter order, `BoundVar`s for trait reference didn't change whether you are in an impl's scope or in an associated item's scope. Now that item's generic params come before its parent's, we need to shift their indices when we are in an associated item's scope.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I am getting an undefined symbol when running a binary compiled with rustc master on kernel version 2.6.18 (which is marked as being supported).
The undefined symbol definitely does not exist on that version of the kernel, which was added in version 2.6.25.
The text was updated successfully, but these errors were encountered: