| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Fix an ICE in the recursion lint
fixes #121170
I looked into it, and there is no good path towards tainting mir_build (where the ICE happens), but using `try_normalize` in a lint seems generally better anyway
|
|
allow mutable references in const values when they point to no memory
Fixes https://github.com/rust-lang/rust/issues/120450
The second commit is just some drive-by test suite cleanup.
r? `@oli-obk`
|
|
Add clippy into the known `cfg` list
In clippy, we are removing the `feature = "cargo-clippy"` cfg to replace it with `clippy` in https://github.com/rust-lang/rust-clippy/pull/12292. But for it to work, we need to declare `clippy` as cfg. It makes it more coherent with other existing tools like rustdoc.
cc `@flip1995`
|
|
For E0038, suggest associated type if available
Closes #116434
|
|
Avoid an ICE in diagnostics
fixes #121004
just a slice usage in diagnostics code. Sadly we can't yet bubble the `ErrorGuaranteed` from wf check to borrowck for these cases, as that causes cycle errors iirc
|
|
suggest `into_iter()` when `Iterator` method called on `impl IntoIterator`
Fix for issue #117711.
|
|
Implement intrinsics with fallback bodies
fixes #93145 (though we can port many more intrinsics)
cc #63585
The way this works is that the backend logic for generating custom code for intrinsics has been made fallible. The only failure path is "this intrinsic is unknown". The `Instance` (that was `InstanceDef::Intrinsic`) then gets converted to `InstanceDef::Item`, which represents the fallback body. A regular function call to that body is then codegenned. This is currently implemented for
* codegen_ssa (so llvm and gcc)
* codegen_cranelift
other backends will need to adjust, but they can just keep doing what they were doing if they prefer (though adding new intrinsics to the compiler will then require them to implement them, instead of getting the fallback body).
cc `@scottmcm` `@WaffleLapkin`
### todo
* [ ] miri support
* [x] default intrinsic name to name of function instead of requiring it to be specified in attribute
* [x] make sure that the bodies are always available (must be collected for metadata)
|
|
|
|
|
|
Use generic `NonZero` internally.
Tracking issue: https://github.com/rust-lang/rust/issues/120257
|
|
Avoid debug logging entire MIR body
If there is a need to examine the MIR body there is -Zmir-dump.
|
|
Only point out non-diverging arms for match suggestions
Fixes #121144
There is no reason to point at diverging arms, which will always coerce to whatever is the match block's evaluated type.
This also removes the suggestion from #106601, since as I pointed out in https://github.com/rust-lang/rust/issues/72634#issuecomment-1946210898 the added suggestion is not firing in the right cases, but instead only when one of the match arms already *actually* evaluates to `()`.
r? estebank
|
|
r=Amanieu
Update aarch64 target feature docs to match LLVM
https://github.com/rust-lang/stdarch/issues/1432 https://github.com/rust-lang/stdarch/pull/1527
r? ```@Amanieu```
|
|
Fix closure kind docs
I didn't review this close enough lol -- the old code snippet didn't use substs correctly, and had a malformed `if let`
|
|
Make `async Fn` trait kind errors better
1. Make it so that async closures with the wrong closurekind actually report a useful error
2. Explain why async closures can sometimes not implement `Fn`/`FnMut` (because they capture things)
r? oli-obk
|
|
Add an ErrorGuaranteed to ast::TyKind::Err (attempt 2)
This makes it more like `hir::TyKind::Err`, and avoids a `has_errors` assertion in `LoweringContext::lower_ty_direct`.
r? ```@oli-obk```
|
|
Skip coroutines in jump threading to avoid query cycles
Fixes #121094
|
|
Consider principal trait ref's auto-trait super-traits in dyn upcasting
Given traits like:
```rust
trait Subtrait: Supertrait + Send {}
trait Supertrait {}
```
We should be able to upcast `dyn Subtrait` to `dyn Supertrait + Send`. This is not currently possible, because when upcasting, we look at the list of auto traits in the object type (`dyn Subtrait`, which has no auto traits in its bounds) and compare them to the target's auto traits (`dyn Supertrait + Send`, which has `Send` in its bound).
Since the target has auto traits that are not present in the source, the upcasting fails. This is overly restrictive, since `dyn Subtrait` will always implement `Send` via its built-in object impl. I propose to loosen this restriction here.
r? types
---
### ~~Aside: Fix this in astconv instead?~~
### edit: This causes too many failures. See https://github.com/rust-lang/rust/pull/119825#issuecomment-1890847150
We may also fix this by by automatically elaborating all auto-trait supertraits during `AstConv::conv_object_ty_poly_trait_ref`. That is, we can make it so that `dyn Subtrait` is elaborated into the same type of `dyn Subtrait + Send`.
I'm open to considering this solution instead, but it would break coherence in the following example:
```rust
trait Foo: Send {}
trait Bar {}
impl Bar for dyn Foo {}
impl Bar for dyn Foo + Send {}
//~^ This would begin to be an overlapping impl.
```
|
|
|
|
|
|
Rollup of 8 pull requests
Successful merges:
- #120449 (Document requirements for unsized {Rc,Arc}::from_raw)
- #120505 (Fix BTreeMap's Cursor::remove_{next,prev})
- #120672 (std::thread update freebsd stack guard handling.)
- #121088 (Implicitly enable evex512 if avx512 is enabled)
- #121104 (Ignore unsized types when trying to determine the size of the original type)
- #121107 (Fix msg for verbose suggestions with confusable capitalization)
- #121113 (Continue compilation even if inherent impl checks fail)
- #121120 (Add `ErrorGuaranteed` to `ast::LitKind::Err`, `token::LitKind::Err`.)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
|
|
If there is a need to examine the MIR body there is -Zmir-dump.
|
|
|
|
the check-cfg list is updated
|
|
Add `ErrorGuaranteed` to `ast::LitKind::Err`, `token::LitKind::Err`.
Similar to recent work doing the same for `ExprKind::Err` (#120586) and `TyKind::Err` (#121109).
r? `@oli-obk`
|
|
Continue compilation even if inherent impl checks fail
We should not be hiding errors behind unrelated errors
|
|
Fix msg for verbose suggestions with confusable capitalization
When encountering a verbose/multipart suggestion that has changes that are only caused by different capitalization of ASCII letters that have little differenciation, expand the message to highlight that fact (like we already do for inline suggestions).
The logic to do this was already present, but implemented incorrectly.
|
|
Ignore unsized types when trying to determine the size of the original type
Fixes https://github.com/rust-lang/rust/issues/121074 a regression from https://github.com/rust-lang/rust/pull/118983
|
|
Implicitly enable evex512 if avx512 is enabled
LLVM 18 requires the evex512 feature to allow use of zmm registers. LLVM automatically sets it when using a generic CPU, but not when `-C target-cpu` is specified. This will result either in backend legalization crashes, or code unexpectedly using ymm instead of zmm registers.
For now, make sure that `avx512*` features imply `evex512`. Long term we'll probably have to deal with the AVX10 mess somehow.
Fixes https://github.com/rust-lang/rust/issues/121081.
r? `@Amanieu`
|
|
|
|
Clean up potential_query_instability with FxIndexMap and UnordMap
From https://github.com/rust-lang/rust/pull/120485#issuecomment-1916437191
r? `@michaelwoerister`
|
|
r=RalfJung,cjgillot
Store static initializers in metadata instead of the MIR of statics.
This means that adding generic statics would be even more difficult, as we can't evaluate statics from other crates anymore, but the subtle issue I have encountered make me think that having this be an explicit problem is better.
The issue is that
```rust
static mut FOO: &mut u32 = &mut 42;
static mut BAR = unsafe { FOO };
```
gets different allocations, instead of referring to the same one. This is also true for non-static mut, but promotion makes `static FOO: &u32 = &42;` annoying to demo.
Fixes https://github.com/rust-lang/rust/issues/61345
## Why is this being done?
In order to ensure all crates see the same nested allocations (which is the last issue that needs fixing before we can stabilize [`const_mut_refs`](https://github.com/rust-lang/rust/issues/57349)), I am working on creating anonymous (from the Rust side, to LLVM it's like a regular static item) static items for the nested allocations in a static. If we evaluate the static item in a downstream crate again, we will end up duplicating its nested allocations (and in some cases, like the `match` case, even duplicate the main allocation).
|
|
static.
Instead we re-use the static's alloc id within the interpreter for its initializer to refer to the `Allocation` that only exists within the interpreter.
|
|
|
|
|
|
|
|
|
|
Rollup of 10 pull requests
Successful merges:
- #111106 (Add known issue of let binding to format_args doc)
- #118749 (Make contributing to windows bindings easier)
- #120982 (Add APIs for fetching foreign items )
- #121022 (rustdoc: cross-crate re-exports: correctly render late-bound params in source order even if early-bound params are present)
- #121082 (Clarified docs on non-atomic oprations on owned/mut refs to atomics)
- #121084 (Make sure `tcx.create_def` also depends on the forever red node, instead of just `tcx.at(span).create_def`)
- #121098 (Remove unnecessary else block from `thread_local!` expanded code)
- #121105 (Do not report overflow errors on ConstArgHasType goals)
- #121116 (Reinstate some delayed bugs.)
- #121122 (Enforce coroutine-closure layouts are identical)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Enforce coroutine-closure layouts are identical
Enforce that for an async closure, the by-ref and by-move coroutine layouts are identical. This is just a sanity check to make sure that optimizations aren't doing anything fishy.
r? oli-obk
|
|
Reinstate some delayed bugs.
These were changed to `has_errors` assertions in #121071 because that seemed reasonable, but evidently not.
Fixes #121103.
Fixes #121108.
|
|
Do not report overflow errors on ConstArgHasType goals
This is 10% of a fix for #121090, since it at least means that we no longer mention the `ConstArgHasType` goal as the cause for the overflow. Instead, now we mention:
```
overflow evaluating the requirement `{closure@$DIR/overflow-during-mono.rs:13:41: 13:44}: Sized`
```
which is not much better, but slightly.
r? oli-obk
|
|
Make sure `tcx.create_def` also depends on the forever red node, instead of just `tcx.at(span).create_def`
oversight from https://github.com/rust-lang/rust/pull/119136
Not actually an issue, because all uses of `tcx.create_def` were in the resolver, which is `eval_always`, but still good to harden against future uses of `create_def`
cc `@petrochenkov` `@WaffleLapkin`
|
|
Add APIs for fetching foreign items
Closes https://github.com/rust-lang/project-stable-mir/issues/61
|
|
|
|
|
|
To avoid some unwrapping.
|
|
This mostly works well, and eliminates a couple of delayed bugs.
One annoying thing is that we should really also add an
`ErrorGuaranteed` to `proc_macro::bridge::LitKind::Err`. But that's
difficult because `proc_macro` doesn't have access to `ErrorGuaranteed`,
so we have to fake it.
|
