| Age | Commit message (Collapse) | Author | Lines |
|---|
|
valtree_to_const_val
|
|
|
|
|
|
Forbid nested opaque types to reference HRTB from opaque types.
Avoids https://github.com/rust-lang/rust/issues/96194
Alternative to https://github.com/rust-lang/rust/pull/96970
r? `@oli-obk`
|
|
|
|
Initial work on Miri permissive-exposed-provenance
Rustc portion of the changes for portions of a permissive ptr-to-int model for Miri. The main changes here are changing `ptr_get_alloc` and `get_alloc_id` to return an Option, and also making ptr-to-int casts have an expose side effect.
|
|
|
|
Drop tracking: handle invalid assignments better
Previously this test case was crashing with an index out of bounds error deep in the call to `needs_drop`. We avoid this by detecting clearly invalid assignees in the `mutate` callback and ignoring these.
|
|
Previously this test case was crashing with an index out of bounds error
deep in the call to `needs_drop`. We avoid this by detecting clearly
invalid assignees in the `mutate` callback and ignoring these.
|
|
|
|
|
|
Fixes https://github.com/rust-lang/rust/issues/93959
This change was accepted in https://rust-lang.github.io/rfcs/2580-ptr-meta.html
Note that this changes the signature of **stable** functions.
The change should be backward-compatible, but it is **insta-stable**
since it cannot (easily, at all?) be made available only
through a `#![feature(…)]` opt-in.
The RFC also proposed the same change for `NonNull::dangling`,
which makes sense it terms of its signature but not in terms of its implementation.
`dangling` uses `align_of()` as an address. But what `align_of()` should be for
extern types or whether it should be allowed at all remains an open question.
This commit depends on https://github.com/rust-lang/rust/pull/93977, which is not yet
part of the bootstrap compiler. So `#[cfg]` is used to only apply the change in
stage 1+. As far a I know bounds cannot be made conditional with `#[cfg]`, so the
entire functions are duplicated. This is unfortunate but temporary.
Since this duplication makes it less obvious in the diff,
the new definitions differ in:
* More permissive bounds (`Thin` instead of implied `Sized`)
* Different implementation
* Having `rustc_allow_const_fn_unstable(ptr_metadata)`
|
|
Signed-off-by: Miguel Guarniz <mi9uel9@gmail.com>
|
|
Add regression test for #28935
Closes #28935, one of the ancient issues can be closed :)
r? `@compiler-errors`
|
|
Add a regression test for #54779
Closes #54779
r? `@jackh726`
|
|
|
|
bounds
|
|
|
|
Be more precise than DefPathData::Misc.
This variant was used for two unrelated things. Let's make this cleaner.
|
|
Add test of matches macro for trailing commas
Almost all macros are tested for trailing commas.
The macro matches! was however not tested.
This PR adds that test case.
Related to #46238
|
|
|
|
Add tests for #96806
I messed up the rebase in https://github.com/rust-lang/rust/pull/96806.
I took the opportunity to add an extra mir-opt test from https://github.com/rust-lang/rust/pull/91743.
r? `@oli-obk`
|
|
|
|
r=estebank
Stop suggesting non-existing fully qualified paths
This patch fixes a part of #96295.
r? `@estebank`
|
|
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.
|
|
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/91743
Closes #69121
Closes #73021
Closes #88599
Closes #93008
Closes #93248
Closes #94680
Closes #96170
r? `@oli-obk`
|
|
|
|
|
|
|
|
In the previous implementation, if the standard streams were open,
but the RLIMIT_NOFILE value was below three, the poll would fail
with EINVAL:
> ERRORS: EINVAL The nfds value exceeds the RLIMIT_NOFILE value.
Switch to the existing fcntl based implementation to avoid the issue.
|
|
|
|
Fix issue #95151
Fixes #95151
Nothing special here, just a test for a thing that used to ICE.
|
|
r=compiler-errors
Use lifetimes on type-alias-impl-trait used in function signatures to infer output type lifetimes
fixes https://github.com/rust-lang/rust/issues/96564
TLDR:
```rust
fn execute(ty: Ty<'_>) -> &str { todo!() }
```
(`Ty` being a type alias impl trait) used to produce the following error before this PR
```
error[E0581]: return type references an anonymous lifetime, which is not constrained by the fn input types
--> src/lib.rs:4:27
|
4 | fn execute(ty: Ty<'_>) -> &str { todo!() }
| ^^^^
|
= note: lifetimes appearing in an associated type are not considered constrained
```
|
|
Add regression test for #68408
Closes https://github.com/rust-lang/rust/issues/68408
|
|
|
|
|
|
|
|
|
|
|
|
Rollup of 6 pull requests
Successful merges:
- #96717 (Handle mismatched generic param kinds in trait impls betterly)
- #96725 (Expose process windows_process_extensions_main_thread_handle on Windows)
- #96849 (Move some tests to more reasonable places)
- #96861 (Use Rust 2021 prelude in std itself.)
- #96879 (rustdoc: search result ranking fix)
- #96882 (Don't subst an AdtDef with its own substs)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Move some tests to more reasonable places
cc https://github.com/rust-lang/rust/issues/73494
r? `@petrochenkov`
|
|
Handle mismatched generic param kinds in trait impls betterly
- Check that generic params on a generic associated type are the same as in the trait definition
- Check that const generics are not used in place of type generics (and the other way round too)
r? `@lcnr`
|
|
output type lifetimes
|
|
Check hidden types for well formedness at the definition site instead of only at the opaque type itself
work towards #90409 . We'll need to look into closure and generator bodies of closures and generators nested inside the hidden type in order to fix that. In hindsight this PR is not necessary for that, but it may be a bit easier with it and we'll get better diagnostics from it on its own.
|
|
|
|
|
