openbsd: convert futex timeout managment to Timespec usage
unbreak openbsd build after #96657
r? cuviper
please note I made `Timespec::zero()` public to be able to use it. OpenBSD is using relative timeout for `futex(2)` and I don't find simple way to use `Timespec` this way.
don't encode only locally used attrs
Part of https://github.com/rust-lang/compiler-team/issues/505.
We now filter builtin attributes before encoding them in the crate metadata in case they should only be used in the local crate. To prevent accidental misuse `get_attrs` now requires the caller to state which attribute they are interested in. For places where that isn't trivially possible, I've added a method `fn get_attrs_unchecked` which I intend to remove in a followup PR.
After this pull request landed, we can then slowly move all attributes to only be used in the local crate while being certain that we don't accidentally try to access them from extern crates.
cc https://github.com/rust-lang/rust/pull/94963#issuecomment-1082924289
diagnostics: port more diagnostics to derive + support for `()` fields
- Extend diagnostic derive so that spanless subdiagnostics (e.g. some uses of `help`/`note`) can be applied via attributes to fields of type `()` (currently spanless subdiagnostics are applied via attributes on the diagnostic struct itself). A consequence of this is that `Option<()>` fields can be used to represent optional spanless subdiagnostics, which are sometimes useful (e.g. for a `help` that should only show on nightly builds).
- Simplify the "explicit generic args with impl trait" diagnostic struct (from #96760) using support for `Option<()>` spanless subdiagnostics.
- Change `DiagnosticBuilder::set_arg`, used to provide context for Fluent messages, so that it takes anything that implements `IntoDiagnosticArg`, rather than `DiagnosticArgValue` - this improves the ergonomics of manual implementations of `SessionDiagnostic` which are translatable.
- Port "the type parameter `T` must be explicitly specified", "manual implementations of `X` are experimental", "could not resolve substs on overridden impl" diagnostics to diagnostic structs.
- When testing macros from `rustc_macros` in `ui-fulldeps` tests, sometimes paths from the compiler source tree can be shown in error messages - these need to be normalized in `compiletest`.
r? `@oli-obk`
cc `@pvdrz`
Port the "the type parameter `T` must be explicitly specified"
diagnostic to using a diagnostic struct.
Signed-off-by: David Wood <david.wood@huawei.com>
Manual implementors of translatable diagnostics will need to call
`set_arg`, not just the derive, so make this function a bit more
ergonomic by taking `IntoDiagnosticArg` rather than
`DiagnosticArgValue`.
Signed-off-by: David Wood <david.wood@huawei.com>
When testing macros from `rustc_macros` in `ui-fulldeps` tests,
sometimes paths from the compiler source tree can be shown in error
messages - these need to be normalized.
Signed-off-by: David Wood <david.wood@huawei.com>
Using new support for spanless subdiagnostics from `()` fields in the
diagnostic derive, simplify the "explicit generic args with impl trait"
diagnostic's struct.
Signed-off-by: David Wood <david.wood@huawei.com>
Type attributes could previously be used to support spanless
subdiagnostics but these couldn't easily be made optional in the same
way that spanned subdiagnostics could by using a field attribute on a
field with an `Option<Span>` type. Spanless subdiagnostics can now be
specified on fields with `()` type or `Option<()>` type.
Signed-off-by: David Wood <david.wood@huawei.com>
Remove `PartialOrd`/`Ord` impl for `PlaceRef`
This is a new attempt at #93315. It removes one usage
of the `Ord` impl for `DefId`, which should make it easier
to eventually remove that impl.
Add `sub_ptr` on pointers (the `usize` version of `offset_from`)
We have `add`/`sub` which are the `usize` versions of `offset`, this adds the `usize` equivalent of `offset_from`. Like how `.add(d)` replaced a whole bunch of `.offset(d as isize)`, you can see from the changes here that it's fairly common that code actually knows the order between the pointers and *wants* a `usize`, not an `isize`.
As a bonus, this can do `sub nuw`+`udiv exact`, rather than `sub`+`sdiv exact`, which can be optimized slightly better because it doesn't have to worry about negatives. That's why the slice iterators weren't using `offset_from`, though I haven't updated that code in this PR because slices are so perf-critical that I'll do it as its own change.
This is an intrinsic, like `offset_from`, so that it can eventually be allowed in CTFE. It also allows checking the extra safety condition -- see the test confirming that CTFE catches it if you pass the pointers in the wrong order.
Like we have `add`/`sub` which are the `usize` version of `offset`, this adds the `usize` equivalent of `offset_from`. Like how `.add(d)` replaced a whole bunch of `.offset(d as isize)`, you can see from the changes here that it's fairly common that code actually knows the order between the pointers and *wants* a `usize`, not an `isize`.
As a bonus, this can do `sub nuw`+`udiv exact`, rather than `sub`+`sdiv exact`, which can be optimized slightly better because it doesn't have to worry about negatives. That's why the slice iterators weren't using `offset_from`, though I haven't updated that code in this PR because slices are so perf-critical that I'll do it as its own change.
This is an intrinsic, like `offset_from`, so that it can eventually be allowed in CTFE. It also allows checking the extra safety condition -- see the test confirming that CTFE catches it if you pass the pointers in the wrong order.
Like we have `add`/`sub` which are the `usize` version of `offset`, this adds the `usize` equivalent of `offset_from`. Like how `.add(d)` replaced a whole bunch of `.offset(d as isize)`, you can see from the changes here that it's fairly common that code actually knows the order between the pointers and *wants* a `usize`, not an `isize`.
As a bonus, this can do `sub nuw`+`udiv exact`, rather than `sub`+`sdiv exact`, which can be optimized slightly better because it doesn't have to worry about negatives. That's why the slice iterators weren't using `offset_from`, though I haven't updated that code in this PR because slices are so perf-critical that I'll do it as its own change.
This is an intrinsic, like `offset_from`, so that it can eventually be allowed in CTFE. It also allows checking the extra safety condition -- see the test confirming that CTFE catches it if you pass the pointers in the wrong order.
Implement a lint to warn about unused macro rules
This implements a new lint to warn about unused macro rules (arms/matchers), similar to the `unused_macros` lint added by #41907 that warns about entire macros.
```rust
macro_rules! unused_empty {
(hello) => { println!("Hello, world!") };
() => { println!("empty") }; //~ ERROR: 1st rule of macro `unused_empty` is never used
}
fn main() {
unused_empty!(hello);
}
```
Builds upon #96149 and #96156.
Fixes#73576
Gracefully fail to resolve associated items instead of `delay_span_bug`.
`codegen_fulfill_obligation` is used during instance resolution for trait items.
In case of insufficient normalization issues during MIR inlining, it caused ICEs.
It's better to gracefully refuse to resolve the associated item, and let the caller decide what to do with this.
Split from https://github.com/rust-lang/rust/pull/91743Closes#69121Closes#73021Closes#88599Closes#93008Closes#93248Closes#94680Closes#96170
r? `@oli-obk`
tighten sanity checks around Scalar and ScalarPair
While investigating https://github.com/rust-lang/rust/issues/96185 I noticed codegen has tighter sanity checks here than Miri does, so I added some more assertions. Strangely, some of them fail, so I also needed to add a HACK... that is probably worth looking into.
This does not fix that issue, but it changes the ICE messages, making it quite clear that we have a scalar whose size is not the same as that of the surrounding layout.
r? `@oli-obk`
PR #94586 added support for using
`rustc_nonnull_optimization_guaranteed` on values where the "null" value
is the all-ones bitpattern.
Now that #94586 has made it to the stage0 compiler, add
`rustc_nonnull_optimization_guaranteed` to `OwnedFd`, `BorrowedFd`,
`OwnedSocket`, and `BorrowedSocket`, since these types all exclude
all-ones bitpatterns.
This allows `Option<OwnedFd>`, `Option<BorrowedFd>`, `Option<OwnedSocket>`,
and `Option<BorrowedSocket>` to be used in FFI declarations, as described
in the [I/O safety RFC].
[I/O safety RFC]: https://github.com/rust-lang/rfcs/blob/master/text/3128-io-safety.md#ownedfd-and-borrowedfdfd-1
logging: add env var to control verbose scope entry/exit logging
~~This got removed in https://github.com/rust-lang/rust/pull/75143, and I find this makes long traces a lot harder to read, so I propose we add this back.~~
Example trace:
```
│ │ ├─0ms INFO rustc_const_eval::interpret::step return
│ │ ├─0ms INFO rustc_const_eval::interpret::eval_context popping stack frame (returning from function)
│ │┌┘rustc_const_eval::interpret::eval_context::frame std::ptr::mut_ptr::<impl *mut u8>::guaranteed_eq
│ ├┘rustc_const_eval::interpret::eval_context::frame std::ptr::mut_ptr::<impl *mut u8>::is_null
│ ├─1ms INFO rustc_const_eval::interpret::step // executing bb2
│ ├─1ms INFO rustc_const_eval::interpret::step StorageDead(_4)
│ ├─1ms INFO rustc_const_eval::interpret::step StorageDead(_2)
│ ├─1ms INFO rustc_const_eval::interpret::step return
│ ├─1ms INFO rustc_const_eval::interpret::eval_context popping stack frame (returning from function)
│┌┘rustc_const_eval::interpret::eval_context::frame std::ptr::mut_ptr::<impl *mut u8>::is_null
├┘rustc_const_eval::interpret::eval_context::frame std::sys_common::thread_local_dtor::register_dtor_fallback::run_dtors
├─178ms INFO rustc_const_eval::interpret::step // executing bb2
├─178ms INFO rustc_const_eval::interpret::step StorageDead(_5)
```
r? `@oli-obk`
Fix inaccurate function name in `rustc_const_eval` docs
Looks to me like this fixes#85513. I had trouble making a intra-docs link to `eval_place_to_op` work, though...
ast: Introduce some traits to get AST node properties generically
And use them to avoid constructing some artificial `Nonterminal` tokens during expansion
r? `@nnethercote` `@Aaron1011`
