Readme: update section on how to run `x.py`
`./x.py` currently looks for `python3` (not `python`) in the `PATH`. I updated that in the readme and also mentioned a convenient way to run `x.py` on Windows. The PowerShell script is actually quite inconvenient to use (and not really necessary on the `cmd.exe` prompt) so I left it out.
In addition I adapted `./x` in one of the CI scripts.
Fix panic on `x build --help --verbose`
See https://github.com/rust-lang/rust/issues/106165 for a detailed description of what went wrong here.
This also makes the panic message a little more informative in case it happens again.
Fix incorrect span when using byte-escaped rbrace
Fix#103826, a format args span issue introduced in #102214.
The current solution for tracking skipped characters made it so that certain situations were ambiguous enough that the original span couldn't be worked out later. This PR improves on the original solution by keeping track of groups of skipped characters using a map, and fixes the previous bug. See an example of this ambiguity in the [previous PR's discussion](https://github.com/rust-lang/rust/pull/102214#issuecomment-1258711015).
Don't perform invalid checks in `codegen_attrs`
The attributes `#[track_caller]` and `#[cmse_nonsecure_entry]` are only valid on functions. When validating one of these attributes, codegen_attrs previously called `fn_sig`, [which can only be used on functions](https://github.com/rust-lang/rust/pull/105201), on the item the attribute was attached to, assuming that the item was a function without checking. This led to [ICEs in situations where the attribute was incorrectly used on non-functions](https://github.com/rust-lang/rust/issues/105594).
With this change, we skip calling `fn_sig` if the item the attribute is attached to must be a function but isn't, because `check_attr` will reject such cases without codegen_attrs's intervention.
As a side note, some of the attributes in codegen_attrs are only valid on functions, but that property isn't actually checked. I'm planning to fix that in a follow up PR since it's a behavior change that will need to be validated rather than an obvious bugfix. Thankfully, all the attributes like that I've found so far are unstable.
Fixes#105594.
r? `@cjgillot`
This PR makes the `464px` version of `#src-sidebar-toggle` the same as the
`700px` version, with the button lower on the page so that it doesn't cover
up the search form, and removes the left margin to make space for it.
fix incorrect suggestion in `suboptimal_flops`
fixes#10003
There was an error when trying to negate an expression like `x - 1.0`. We used to format it as `-x - 1.0` whereas a proper negation would be `-(x - 1.0)`.
Therefore, we add parentheses around the expression when it is `ExprKind::Binary`.
We also add parentheses around multiply and divide expressions, even though this is not strictly necessary.
changelog: [`suboptimal_flops`]: fix incorrect suggestion caused by an incorrect negation of floating point expressions.
There was an error when trying to negate an expression
like `x - 1.0`. We used to format it as `-x - 1.0` whereas
a proper negation would be `-(x - 1.0)`.
Therefore, we add parentheses around the expression when it is a
Binary ExprKind.
We also add parentheses around multiply and divide expressions,
even though this is not strictly necessary.
Remove wrapper functions for some unstable options
They are trivial and just forward to the option. Like most other options, we can just access it directly.
abort immediately on bad mem::zeroed/uninit
Now that we have non-unwinding panics, let's use them for these assertions. This re-establishes the property that `mem::uninitialized` and `mem::zeroed` will never unwind -- the earlier approach of causing panics here sometimes led to hard-to-debug segfaults when the surrounding code was not able to cope with the unexpected unwinding.
Cc `@bjorn3` I did not touch cranelift but I assume it needs a similar patch. However it has a `codegen_panic` abstraction that I did not want to touch since I didn't know how else it is used.
