Fixes#18037 "TypedArena cannot handle zero-sized types".
Closes#17931 "improve chunk allocation scheme used by Arena / TypedArena".
Closes#22847 "TypedArena should implement Send". - N.B. Arena cannot implement Send, since it may contain non-Send values.
Closes#18471 "`Arena::alloc_copy_inner` (at least) should be renamed and made public." - Added `Arena::alloc_bytes`.
Closes#18261 "support clearing TypedArena with the chunks preserved". - Only the largest chunk is preserved.
Fix a bug allowing an item and an external crate to collide so long as the external crate is declared after the item. For example,
```rust
mod core { pub fn f() {} } // This would be an error if it followed the `extern crate`
extern crate core; // This declaration is shadowed by the preceding module
fn main() { core::f(); }
```
This is a [breaking-change], but it looks unlikely to cause breakage in practice, and any breakage can be fixed by removing colliding `extern crate` declarations, which are shadowed and hence unused.
This just removes the `Some()` that appeared around terminators in MIR text output after https://github.com/rust-lang/rust/pull/30481 (cc @nagisa). The graphviz is already fixed.
r? @eddyb
the problem is that now "type_is_known_to_be_sized" now returns
false when called on a type with ty_err inside - this prevents
spurious errors (we may want to move the check to check::cast
anyway - see #12894).
len needs to be prefixed by self for this to work. That is something which trips me up all the time. It's reassuring to see that happening to seasoned Rust programmers.
I'm working my way through TRPL beginning at "Syntax and Semantics" as was recommended in a previous version.
I'm expecting the chapter to incrementally build up my knowledge of the language section by section, assuming no prior Rust experience. So it was a bit of a speed-bump to encounter references and the vector type in a code example long before they had been defined and explained.
Another commit in this PR tries to make consistent what is a "chapter" of TRPL versus a "section." Just a nit-pick, but not thinking about that stuff keeps my focus on the important material.
My background: Python programmer since ~2000, with moderate exposure to C, C++, assembly, operating systems, and system architecture in university several years ago.
For your kind consideration, feel welcome to use or drop or rework any part of this.
Fixes#30674
The test seems to work fine and assertion passes. The test seems to also be generated from MIR (LLVM IR has footprint of MIR translator), thus I’m reenabling it.
Previously it was returning a value, mostly for the two reasons:
* Cloning Lvalue is very cheap most of the time (i.e. when Lvalue is not a Projection);
* There’s users who want &mut lvalue and there’s users who want &lvalue. Returning a value allows
to make either one easier when pattern matching (i.e. Some(ref dest) or Some(ref mut dest)).
However, I’m now convinced this is an invalid approach. Namely the users which want a mutable
reference may modify the Lvalue in-place, but the changes won’t be reflected in the final MIR,
since the Lvalue modified is merely a clone.
Instead, we have two accessors `destination` and `destination_mut` which return a reference to the
destination in desired mode.
macro future proofing rules.
(We may want to think about what this test was actually testing and
figure out a way to test it without running afoul of macro future
proofing. I spent some time trying to do this, e.g. by inserting
parenthesis in the macro input pattern, but I could not quickly get it
working, so I took this tack instead.)
After a call to `visit_def_id()` missing in `mir::visit::Visitor` but not `mir::visit::MutVisitor` has caused me a couple hours of error hunting, I decided I'd take the time to get rid of the code duplication between the two implementations.
cc @rust-lang/compiler
See RFC amendment 1384 and tracking issue 30450:
https://github.com/rust-lang/rfcs/pull/1384https://github.com/rust-lang/rust/issues/30450
Moved old check_matcher code into check_matcher_old
combined the two checks to enable a warning cycle (where we will
continue to error if the two checks agree to reject, accept if the new
check says accept, and warn if the old check accepts but the new check
rejects).
