fix a false positive in two `interior_mutable_const` lints where a constant with enums gets linted
even if it uses a clearly unfrozen variant. Note that the code uses the MIR interpreter, which
the author of #3962 thought unlikely to be a solution. This might be over-engineering;
but, I think it's important to be able to work with the 'http' crate (#3825).
* remove a 'ERROR' comment from `borrow`
`Vec<AtomicUsize>` itself is `Freeze` as it holds the atomic in heap
* remove `ONCE_INIT` from `declare`
it seems like an artifact from previous spliting
Lint for invisible Unicode characters other than ZWSP
This PR extends the existing `zero_width_space` lint to look for other invisible characters as well (in this case, `\\u{ad}` soft hyphen.
I feel like this lint is the logical place to add the check, but I also realize the lint name is not particularly flexible, but I also understand that it shouldn't be renamed for compatibility reasons.
Open questions:
- What other characters should trigger the lint?
- What should be done with the lint name?
- How to indicate the change in functionality?
Motivation behind this PR: https://github.com/rust-lang/rust/issues/77417 - I managed to shoot myself in the foot by an invisible character pasted into my test case.
changelog: rename [`zero_width_space`] to [`invisible_characters`] and add SHY and WJ to the list.
Downgrade interior_mutable_const lints to warn by default
This change updates the two lints in the file non_copy_const.rs to be warn by default rather than deny by default. It also updates the known problems for declare_interior_mutable_const to mention some issues that are affected by the lints.
This is a repeat pull request since I botched the first one (#6012). Apart from my messing up the commits of that one, I also had a problem where the stderr of the tests didn't change despite me changing both lints to warn by default. Is this normal behaviour for some lints or do I need to adjust the tests to accommodate the change?
fixes#5863
changelog: none
Don't emit a lint for the suggestion leading to errors in `needless_range_loop`
Fix#5945
changelog: Don't emit a lint for the suggestion leading to errors in `needless_range_loop`
needless arbitrary self: handle macros
This fixes two cases related to macros:
* If the parameter comes from expansion, do not lint as the user has no possibility of changing it. This is not directly related to the fixed issue, but we should probably do that.
* If *only* the lifetime name comes from expansion, lint, but allow the user decide the name of the lifetime. In the related issue, the lifetime was unnamed and then renamed by `async_trait`, so just removing the name in the suggestion would work, but in the general case a macro can rename a lifetime that was named differently, and we can't reliably know that name anymore.
As a hint for the reviewer, the expanded code for the test can be checked with this command (from the root dir of the repo):
```sh
rustc -L target/debug/test_build_base/needless_arbitrary_self_type_unfixable.stage-id.aux -Zunpretty=expanded tests/ui/needless_arbitrary_self_type_unfixable.rs
```
changelog: [`needless_arbitrary_self_type`]: handle macros
Fixes#6089
Add option to pass a custom codegen backend from a driver
This allows the driver to pass information to the codegen backend. For example the headcrab debugger may in the future want to use cg_clif to JIT code to be injected in the debuggee. This would PR make it possible to tell cg_clif which symbol can be found at which address and to tell it to inject the JITed code into the right process.
This PR may also help with https://github.com/rust-lang/miri/pull/1540 by allowing miri to provide a codegen backend that only emits metadata and doesn't perform any codegen.
cc @nbaksalyar (headcrab)
cc @RalfJung (miri)
