Unify all uses of 'gcx and 'tcx.
This is made possible by @Zoxc landing #57214 (see https://github.com/rust-lang/rust/pull/57214#issuecomment-465036053 for the decision).
A bit of context for the approach: just like #61722, this is *not* how I originally intended to go about this, but @Zoxc and my own experimentation independently resulted in the same conclusion:
The interim alias `type TyCx<'tcx> = TyCtxt<'tcx, 'tcx>;` attempt required more work (adding `use`s), even only for handling the `TyCtxt<'tcx, 'tcx>` case and not the general `TyCtxt<'gcx, 'tcx>` one.
What this PR is based on is the realization that `'gcx` is a special-enough name that it can be replaced, without caring for context, with `'tcx`, and then repetitions of the name `'tcx` be compacted away.
After that, only a small number of error categories remained, each category easily dealt with with either more mass replacements (e.g. `TyCtxt<'tcx, '_>` -> `TyCtxt<'tcx>`) or by hand.
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 and #61722, and like the latter, there was also a weird bug to work around.
It should be reviewed separately, and dropped if unwanted (in this PR it's pretty significant).
cc @rust-lang/compiler r? @nikomatsakis
docs: Use String in Rc::into_raw examples
It is unclear if accessing an integer after `drop_in_place` has been
called on it is undefined behaviour or not, as demonstrated by the
discussion in
https://github.com/rust-lang/rust/pull/60766#pullrequestreview-243414222.
Avoid these uncertainties by using String which frees memory in its
`drop_in_place` to make sure this is undefined behaviour. The message in
the docs should be to watch out and not access the data after that, not
discussing when one maybe could get away with it O:-).
in which we decline to suggest the anonymous lifetime in declarations
The elided-lifetimes-in-path lint (part of our suite of Rust 2018 idiom lints which we are hoping to promote to Warn status) was firing with an illegal suggestion to write an anonymous lifetime in a
struct/item declaration (where we don't allow it). The linting code was already deciding whether to act on the basis of a `ParamMode` enum, indicating whether the present path-segment was part of an
expression, or anywhere else. The present case seemed to be part of the "anywhere else", and yet meriting different rules as far as the lint was concerned, so it seemed expedient to introduce a new enum member. We yank out `TyKind::Path` arm into its own method so that we can call it with our new `ParamMode` specifically when lowering struct fields—one would have hoped to think of something more elegant than this, but it definitely beats changing the signature of `lower_ty` to take a `ParamMode`!
Resolves#61124.
cc @memoryruins
r? @oli-obk
The elided-lifetimes-in-path lint (part of our suite of Rust 2018
idiom lints which we are hoping to promote to Warn status) was firing
with an illegal suggestion to write an anonymous lifetime in a
struct/item declaration (where we don't allow it). The linting code
was already deciding whether to act on the basis of a `ParamMode`
enum, indicating whether the present path-segment was part of an
expression, or anywhere else. The present case seemed to be part of
the "anywhere else", and yet meriting different rules as far as the
lint was concerned, so it seemed expedient to introduce a new enum
member. We yank out a `TyKind::Path` arm into its own method so that
we can call it with our new `ParamMode` specifically when lowering
struct fields. (The alternative strategy of changing the signature of
`lower_ty` to take a `ParamMode` would be inelegant given that most of
the `TyKind` match arm bodies therein don't concern themselves with
`ParamMode`.)
Resolves#61124.
Bootstrap cleanup
Each commit is (mostly) standalone and probably best reviewed as such. Nothing too major just some drive-by nits as I was looking through the code.
r? @alexcrichton
ci: Enable toolstate tracking on Azure
Currently just run it through its paces but don't actually push to
official locations. Instead let's just push to a separate fork (mine) as
well as open issues in a separate fork (mine). Make sure that people
aren't pinged for these issues as well!
This should hopefully ensure that everything is working on Azure and
give us a chance to work through any issues that come up.
Fixes https://github.com/rust-lang/rust/issues/61790
Fixes https://github.com/rust-lang/rust/issues/61371
Removing the tool argument in the previous commit means it's no longer
restricted to just bootstrap tools despite being written as such.
Inlining it prevents accidental use.
Currently just run it through its paces but don't actually push to
official locations. Instead let's just push to a separate fork (mine) as
well as open issues in a separate fork (mine). Make sure that people
aren't pinged for these issues as well!
This should hopefully ensure that everything is working on Azure and
give us a chance to work through any issues that come up.
std: Remove internal definitions of `cfg_if!` macro
This is duplicated in a few locations throughout the sysroot to work
around issues with not exporting a macro in libstd but still wanting it
available to sysroot crates to define blocks. Nowadays though we can
simply depend on the `cfg-if` crate on crates.io, allowing us to use it
from there!
It is unclear if accessing an integer after `drop_in_place` has been
called on it is undefined behaviour or not, as demonstrated by the
discussion in
https://github.com/rust-lang/rust/pull/60766#pullrequestreview-243414222.
Avoid these uncertainties by using String which frees memory in its
`drop_in_place` to make sure this is undefined behaviour. The message in
the docs should be to watch out and not access the data after that, not
discussing when one maybe could get away with it O:-).
Changes:
````
Fix wrong lifetime of TyCtxt
travis: Wait at most 30 minutes for base test
Typos and minor grammar corrections
Adds lint for integer division
redundant_closure_for_method_calls fixes: lint does not trigger when there is a difference in mutability lint does not trigger when the method belongs to a trait which is not implemebted directly (Deref)
Fix implicit_return docs
rustup https://github.com/rust-lang/rust/pull/61758/files
Remove wrong lifetime from LintContext
Workaround for rust-lang/rustfmt#3615
Fixing eta with respect to lazy evaluation.
````
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
