| Age | Commit message (Collapse) | Author | Lines |
|
and some uses of it will be illegal forever
(e.g. mutable or interior mutable statics)
|
|
|
|
|
|
|
|
Rollup of 6 pull requests
Successful merges:
- #67148 ( Refactor type & bounds parsing thoroughly)
- #67410 (Reenable static linking of libstdc++ on windows-gnu)
- #67439 (Cleanup `lower_pattern_unadjusted` & Improve slice pat typeck)
- #67480 (Require issue = "none" over issue = "0" in unstable attributes)
- #67500 (Tweak non_shorthand_field_patterns' suggestion)
- #67504 (Warn against relying on ?Sized being last)
Failed merges:
r? @ghost
|
|
|
|
|
|
|
|
constant contexts
|
|
Split up ptr/mod.rs in libcore...
...one with implementation detail for const ptr and the other with mut ptr
I am not sure if the "stable since 1.0.0" flags are the correct choice for the two additional mods.
Also, is it necessary for them to be "pub"? If so, there should be a good description for them.
Closes #66891
|
|
Add a raw "address of" operator
* Parse and feature gate `&raw [const | mut] expr` (feature gate name is `raw_address_of`)
* Add `mir::Rvalue::AddressOf`
* Use the new `Rvalue` for:
* the new syntax
* reference to pointer casts
* drop shims for slices and arrays
* Stop using `mir::Rvalue::Cast` with a reference as the operand
* Correctly evaluate `mir::Rvalue::{Ref, AddressOf}` in constant propagation
cc @Centril @RalfJung @oli-obk @eddyb
cc #64490
|
|
r=estebank
Indicate origin of where type parameter for uninferred types
Based on #65951 (which is not merge yet), fixes #67277.
This PR improves a little the diagnostic for code like:
```
async fn foo() {
bar().await;
}
async fn bar<T>() -> () {}
```
by showing:
```
error[E0698]: type inside `async fn` body must be known in this context
--> unresolved_type_param.rs:9:5
|
9 | bar().await;
| ^^^ cannot infer type for type parameter `T` declared on the function `bar`
|
...
```
(The
```
declared on the function `bar`
```
part is new)
A small side note: `Vec` and `slice` seem to resist this change, because querying `item_name()` panics, and `get_opt_name()` returns `None`.
r? @estebank
|
|
and the other with mut ptr
|
|
|
|
|
|
|
|
Enable `loop` and `while` in constants behind a feature flag
This PR is an initial implementation of #52000. It adds a `const_loop` feature gate, which allows `while` and `loop` expressions through both HIR and MIR const-checkers if enabled. `for` expressions remain forbidden by the HIR const-checker, since they desugar to a call to `IntoIterator::into_iter`, which will be rejected anyways.
`while` loops also require [`#![feature(const_if_match)]`](https://github.com/rust-lang/rust/pull/66507), since they have a conditional built into them. The diagnostics from the HIR const checker will suggest this to the user.
r? @oli-obk
cc @rust-lang/wg-const-eval
|
|
r=centril
Revert stabilization of never type
Fixes https://github.com/rust-lang/rust/issues/66757
I decided to keep the separate `never-type-fallback` feature gate, but tried to otherwise revert https://github.com/rust-lang/rust/pull/65355. Seemed pretty clean.
( cc @Centril, author of #65355, you may want to check this over briefly )
|
|
|
|
This reverts commit 8f6197f39f7d468dfc5b2bd41dae4769992a2f83.
|
|
Require stable/unstable annotations for the constness of all stable fns with a const modifier
r? @RalfJung @Centril
Every `#[stable]` const fn now needs either a `#[rustc_const_unstable]` attribute or a `#[rustc_const_stable]` attribute. You can't silently stabilize the constness of a function anymore.
|
|
|
|
Point at method call when type annotations are needed
- Point at method call instead of whole expression when type annotations are needed.
- Suggest use of turbofish on function and methods.
Fix #49391, fix #46333, fix #48089. CC #58517, #63502, #63082.
Fixes https://github.com/rust-lang/rust/issues/40015
r? @nikomatsakis
|
|
|
|
|
|
Co-Authored-By: Mazdak Farrokhzad <twingoow@gmail.com>
|
|
|
|
|
|
|
|
|
|
functions with a `const` modifier
|
|
|
|
features
|
|
|
|
Ensure that panicking in constants eventually errors
based on #67134
closes #66975
r? @oli-obk
|
|
Ensure that we get a hard error on generic ZST constants if their bod…
…y causes an error during evaluation
cc #67083 (does not fix because we still need the beta backport)
r? @wesleywiser
cc @RalfJung
|
|
|
|
|
|
causes an error during evaluation
|
|
Implement #[track_caller] attribute. (RFC 2091 4/N)
Implements the `#[track_caller]` attribute in both const and codegen contexts.
The const implementation walks up the stack to find the nearest untracked callsite.
The codegen implementation adds an implicit argument to tracked function calls, and populates it with either a call to the previously-landed intrinsic or if the caller has `#[track_caller]` with a copy of the location passed to the current function.
Also includes a little cleanup and a few comments in the other caller location areas.
[Depends on: 65664](https://github.com/rust-lang/rust/pull/65664)
[RFC 2091 text](https://github.com/rust-lang/rfcs/blob/master/text/2091-inline-semantic.md)
[Tracking issue](https://github.com/rust-lang/rust/issues/47809)
[Tracking doc](https://paper.dropbox.com/doc/track_rfc_2091_impl-notes--Anf1NwnIb0xcRv31YLIadyj0Ag-rwCdRc2fi2yvRZ7syGZ9q#:uid=863513134494965680023183&h2=TODO-actually-pass-location-to)
|
|
Miri core engine: use throw_ub instead of throw_panic
See https://github.com/rust-lang/rust/issues/66902 for context: panicking is not really an "interpreter error", but just part of a normal Rust execution. This is a first step towards removing the `InterpError::Panic` variant: the core Miri engine does not use it any more.
ConstProp and ConstEval still use it, though. This will be addressed in future PRs.
From what I can tell, all the error messages this removes are actually duplicates.
r? @oli-obk @wesleywiser
|
|
Add feature gate for mut refs in const fn
r? @oli-obk
|
|
|
|
|
|
|
|
Organize intrinsics promotion checks
cc @vertexclique
supersedes #61835
r? @RalfJung
|
|
[const-prop] Fix ICE calculating enum discriminant
Fixes #66787
Different approach than #66857
r? @oli-obk
cc @RalfJung @eddyb
|
|
Fixes #66787
|
|
|
|
|