Change error reporting of conflicting loans to stop earlier after printing
an error for a given borrow, instead of proceeding to error on possibly every
issued loan. This keeps us down to O(n) errors (for n problem lines), instead
of O(n^2) errors in some cases.
Fixes#27485.
This commit generalises parsing of associative operators from left-associative
only (with some ugly hacks to support right-associative assignment) to properly
left/right-associative operators.
Parsing still is not general enough to handle non-associative,
non-highest-precedence prefix or non-highest-precedence postfix operators (e.g.
`..` range syntax), though. That should be fixed in the future.
Lastly, this commit adds support for parsing right-associative `<-` (left arrow)
operator with precedence higher than assignment as the operator for placement-in
feature.
this has the funky side-effect of also allowing constant evaluation of function calls to functions that are not `const fn` as long as `check_const` didn't mark that function `NOT_CONST`
It's still not possible to call a normal function from a `const fn`, but let statements' initialization value can get const evaluated (this caused the fallout in the overflowing tests)
we can now do this:
```rust
const fn add(x: usize, y: usize) -> usize { x + y }
const ARR: [i32; add(1, 2)] = [5, 6, 7];
```
also added a test for destructuring in const fn args
```rust
const fn i((a, b): (u32, u32)) -> u32 { a + b } //~ ERROR: E0022
```
This is a **[breaking change]**, since it turns some runtime panics into compile-time errors. This statement is true for ANY improvement to the const evaluator.
I could have added a check for explicit recursion, as irregular types
tend to cause selection errors, but I am not sufficiently sure that
cannot be bypassed.
Fixes#22919Fixes#25639Fixes#26548
As displayed before this commit, I found the book confusing in its
explanation of `#`-led comments in `rust` blocks. Possibly the
biggest confusion was because the many-dashes construct does not
become an HR element in the Markdown translator used, so things were
not being properly set off.
This change should more clearly show the as-rendered content as
rendered, and the as-coded content as code.
These commits revert https://github.com/rust-lang/rust/pull/28504 and add a regression test pointed out by @petrochenkov, it's not immediately clear with the regression that the accessibility check should be removed, so for now preserve the behavior on stable by default.
r? @nrc
I didn't see anything particularly weird here. The last commit has the only changes I'm not 100% sure about.
I ignored tables.rs since it's genrated, but I updated the python script that generates it.
?r @nrc
This PR switches the implemented ordering from `unsafe const fn` (as was in the original RFC) to `const unsafe fn` (which is what the lang team decided on)
As discovered in #29298, `env::set_var("", "")` will panic, but it turns out
that it *also* deadlocks on Unix systems. This happens because if a panic
happens while holding the environment lock, we then go try to read
RUST_BACKTRACE, grabbing the environment lock, causing a deadlock.
Specifically, the changes made here are:
* The environment lock is pushed into `std::sys` instead of `std::env`. This
also only puts it in the Unix implementation, not Windows where the functions
are already threadsafe.
* The `std::sys` implementation now returns `io::Result` so panics are
explicitly at the `std::env` level. The panic messages have also been improved
in these situations.
Previously, if you copied a signature from a trait definition such as:
```rust
fn foo<'a>(&'a Bar) -> bool {}
```
and moved it into an `impl`, there would be an error message:
"unexpected token `'a`"
Adding to the error message that a pattern is expected should help
users to find the actual problem with using a lifetime here.
I somehow missed a word behind the numbers while going through this section, don't know what the best approach would be though since "**available** addresses" sounds good to me, too".
