Include frame pointer for bare metal RISC-V targets
This changes the default setting to enable the use of the frame pointer register when targeting RISC-V. On that architecture there is a dedicated frame pointer register which LLVM would otherwise never use so there is no increase in register pressure. Further, since these are bare metal targets, getting backtraces without the frame pointer is considerably more difficult (you can't just ask the OS to load the ELF executable and parse DWARF symbols). It is true that this setting can also be changed with the `-C force-frame-pointers` flag but that won't impact the compilation of the standard library, meaning that backtraces from, say, a panic handler would be useless.
Hygienize macros in the standard library
Same as https://github.com/rust-lang/rust/pull/55597, but for all macros in the standard library.
Nested macro calls will now call what they are intended to call rather than whatever is in the closest scope at call site.
Technically this is a breaking change, so crater run would probably be useful.
---
One exception that is not hygienized is calls to `panic!(...)`.
Macros defined in libcore do not want to call `core::panic`.
What they really want to call is either `std::panic` or `core::panic` depending on `no_std` settings.
EDIT: After some thought, recursive calls to `panic` from `panic` itself probably do want to use `$crate` (UPDATE: done).
Calling `std::panic` from macros defined in std and "whatever `panic` is in scope" from macros defined in libcore is probably even worse than always calling "whatever `panic` is in scope", so I kept the existing code.
The only way to do the std/core switch correctly that I'm aware of is to define a built-in panic macro that would dispatch to `std::panic` or `core::panic` using compiler magic.
Then standard library macros could delegate to this built-in macro.
The macro could be named `panic` too, that would fix https://github.com/rust-lang/rust/issues/61567.
(This PR doesn't do that.)
---
cc https://github.com/rust-lang/rust/issues/56389
cc https://github.com/rust-lang/rust/issues/61567
Fixes https://github.com/rust-lang/rust/issues/61699
r? @alexcrichton
Special-case literals in `parse_bottom_expr`.
This makes parsing faster, particularly for code with large constants,
for two reasons:
- it skips all the keyword comparisons for literals;
- it skips the allocation done by the `mk_expr` call in
`parse_literal_maybe_minus`.
r? @petrochenkov
rustc: replace `TyCtxt<'a, 'gcx, 'tcx>` with `TyCtxt<'gcx, 'tcx>`.
This first lifetime parameter of `TyCtxt` has been phantom for a while, thanks to @Zoxc, but was never removed, and I'm doing this now in preparation for removing the `'gcx`/`'tcx` split.
I wasn't going to do this as a separate step, and instead start converting uses of `TyCtxt` to a single-lifetime alias of it (e.g. `type TyCx<'tcx> = TyCtxt<'tcx, 'tcx, 'tcx>;`) but it turns out (as @Zoxc rightly predicted) that there is far more fallout from not needing a lifetime for the first parameter of `TyCtxt`.
That is, going from `TyCtxt<'a, 'gcx, 'tcx>` to `TyCtxt<'tcx, 'gcx, 'tcx>` (the first commit in this PR) has the largest amount of fallout out of all the changes we might make (because it can require removing the `'a` parameter of `struct`s containing `tcx: TyCtxt<'a, ...>`), and is the hardest to automate (because `'a` is used everywhere, not just with `TyCtxt`, unlike, say `'gcx, 'tcx` -> `'tcx`).
So I'm submitting this now to get it out of the way and reduce further friction in the future.
**EDIT**: for the `rustfmt` commit, I used https://github.com/rust-lang/rustfmt/issues/1324#issuecomment-482109952, and manually filtered out some noise, like in #61735, but unlike that PR, there was also a weird bug to work around.
It should be reviewed separately, and dropped if unwanted.
cc @rust-lang/compiler r? @nikomatsakis
ci: Disable LLVM/debug assertions for distcheck
The purpose of distcheck is to test `./x.py test` from a tarball, not to
test that all assertions pass all the time. These assertions are largely
just redundant with other builders, so skip the assertions for now and
save a good chunk of time on CI.
cc #61185
Allow attributes in formal function parameters
Implements https://github.com/rust-lang/rust/issues/60406.
This is my first contribution to the compiler and since this is a large and complex project, I am not fully aware of the consequences of the changes I have made.
**TODO**
- [x] Forbid some built-in attributes.
- [x] Expand cfg/cfg_attr
Rollup of 9 pull requests
Successful merges:
- #60187 (Generator optimization: Overlap locals that never have storage live at the same time)
- #61348 (Implement Clone::clone_from for Option and Result)
- #61568 (Use Symbol, Span in libfmt_macros)
- #61632 (ci: Collect CPU usage statistics on Azure)
- #61654 (use pattern matching for slices destructuring)
- #61671 (implement nth_back for Range(Inclusive))
- #61688 (is_fp and is_floating_point do the same thing, remove the former)
- #61705 (Pass cflags rather than cxxflags to LLVM as CMAKE_C_FLAGS)
- #61734 (Migrate rust-by-example to MdBook2)
Failed merges:
r? @ghost
