Add a new `compare_bytes` intrinsic instead of calling `memcmp` directly
As discussed in #113435, this lets the backends be the place that can have the "don't call the function if n == 0" logic, if it's needed for the target. (I didn't actually *add* those checks, though, since as I understood it we didn't actually need them on known targets?)
Doing this also let me make it `const` (unstable), which I don't think `extern "C" fn memcmp` can be.
cc `@RalfJung` `@Amanieu`
Add a new `compare_bytes` intrinsic instead of calling `memcmp` directly
As discussed in #113435, this lets the backends be the place that can have the "don't call the function if n == 0" logic, if it's needed for the target. (I didn't actually *add* those checks, though, since as I understood it we didn't actually need them on known targets?)
Doing this also let me make it `const` (unstable), which I don't think `extern "C" fn memcmp` can be.
cc `@RalfJung` `@Amanieu`
Nest other codegen test topics
This PR is like rust-lang/rust#114229 in that it mostly pushes codegen tests around, shoving them into their own directories, but because all of the changes are very simple cleanups I pulled them into a separate PR. The other PR might involve actually evaluating the correctness of the test after changes, but here it is mostly a matter of taste. The only "functional" change is deleting a few tests that... hinge on a version of LLVM that we don't support (as of rust-lang/rust#114148 anyways).
I considered a few different ways to group other topics but I feel the question of whether `tests/codegen/{vec,array,slice}` should exist is more subtle than these choices, as it might be better to group such related tests by other topics like bounds check elision, thus I avoided making it.
Nest tests/codegen/sanitizer*.rs tests in sanitizer dir
The sanitizer tests are the largest and most meticulously tested set of tests in tests/codegen. That's good! They all clearly belong to a subject and thus could go in a directory, but are not, instead being placed simply in tests/codegen. That's bad! Fix this by placing them in their own directory and renaming them to be less repetitive after that move.
A few tests are brittle, and embed their filename in the test's checks. This is acceptable for the ones where it is used only two times, but one test embeds the test's mangled filename in the test *over 50 times*! This may have been one of the things discouraging anyone from moving it, and thus from moving the set. Fortunately, I have some knowledge of Itanium mangling (involuntarily), regex, and the FileCheck syntax. With a capturing variable, FileCheck allows us to now move this test around again without diffing it on ~50 lines, while still guaranteeing that the mangled substring is the same each time.
This also clarifies why the substring is repeated a zillion times, instead of being cryptic. They don't call it mangling because the result is pretty and easy to understand, but now it is slightly easier! Yay descriptive variables!
fix(ci): Ensure idempotence of user creation
Previously, re-running `run.sh` in the same container would fail at the useradd step, because the user already exists. Instead, change that step to "create if not exists" semantics to ease interactive debugging of CI failures.
Split out from https://github.com/rust-lang/rust/pull/111891 per request by `@jackh726`
Add more context to `quit_if_file_exists` in `configure.py` & delete config.toml in CI
If the `obj` directory isn't empty, the error message is subtle and not very helpful:
```
== clock drift check ==
local time: Sun Jul 2 00:57:06 UTC 2023
network time: Sun, 02 Jul 2023 00:57:06 GMT
== end clock drift check ==
sccache: Starting the server...
configure: error: Existing 'config.toml' detected.
== clock drift check ==
local time: Sun Jul 2 00:57:06 UTC 2023
network time: Sun, 02 Jul 2023 00:57:06 GMT
== end clock drift check ==
```
This makes it stand out and suggests how to resolve the issue:
```
== clock drift check ==
local time: Sun Jul 2 02:11:30 UTC 2023
network time: Sun, 02 Jul 2023 02:11:31 GMT
== end clock drift check ==
sccache: Starting the server...
configure: ERROR: Existing 'config.toml' detected. Exiting
Is objdir '/home/tmgross/projects/rust/obj' clean?
== clock drift check ==
local time: Sun Jul 2 02:11:31 UTC 2023
network time: Sun, 02 Jul 2023 02:11:31 GMT
== end clock drift check ==
```
Rollup of 6 pull requests
Successful merges:
- #114535 (bump schannel, miow to drop windows-sys 0.42)
- #114542 (interpret: use ConstPropNonsense for more const-prop induced issues)
- #114543 (add tests for some fixed ConstProp ICEs)
- #114550 (Generate better function argument names in global_allocator expansion)
- #114556 (Issue numbers are enforced on active features; remove FIXME)
- #114558 (Remove FIXME about NLL diagnostic that is already improved)
Failed merges:
- #114485 (Add trait decls to SMIR)
r? `@ghost`
`@rustbot` modify labels: rollup
Remove FIXME about NLL diagnostic that is already improved
The FIXME was added in #46984 when the diagnostic message looked like this:
// FIXME(#46983): error message should be better
&s.0 //~ ERROR free region `` does not outlive free region `'static`
The message was improved in #90667 and now looks like this:
&s.0 //~ ERROR lifetime may not live long enough
but the FIXME was not removed. The issue #46983 about that diagnostics should be improved has been closed. We can remove the FIXME now.
(This PR was made for #44366.)
Issue numbers are enforced on active features; remove FIXME
Since https://github.com/rust-lang/rust/pull/51090 tidy enforces that active features have an issue number, so remove the FIXME.
This PR is part of #44366 which is E-help-wanted.
Steal MIR for CTFE when possible.
Some bodies, like constants, have CTFE MIR but no optimized MIR.
In that case, have `mir_for_ctfe` steal the MIR instead of cloning it.
The FIXME was added in 46984 when the diagnostic message looked like
this:
// FIXME(#46983): error message should be better
&s.0 //~ ERROR free region `` does not outlive free region `'static`
The message was improved in 90667 and now looks like this:
&s.0 //~ ERROR lifetime may not live long enough
but the FIXME was not removed. The issue 46983 about that diagnostics
should be improved has been closed. We can remove the FIXME now.
redundant_type_annotations: only pass certain def kinds to type_of
Fixes#11190Fixesrust-lang/rust#113516
Also adds an `is_lint_allowed` check to skip the lint when it's not needed
changelog: none
Don't provide `generate_default_from_new` when impl self ty is missing
Also don't provide the assist when the `Default` trait can't be found.
Part of #15398
New lints: `impossible_comparisons` and `redundant_comparisons`
Inspired by a bug we had in production, like all good lints ;)
Adds two lints for "double" comparisons, specifically when the same expression is being compared against two different constants.
`impossible_comparisons` checks for expressions that can never be true at all. Example:
```rust
status_code <= 400 && status_code > 500
```
Presumably, the programmer intended to write `status_code >= 400 && status_code < 500` in this case.
`redundant_comparisons` checks for expressions where either half has no effect. Example:
```rust
status_code <= 400 && status_code < 500
```
Works with other literal types like floats and strings, and *some* cases where the constant is more complex than a literal, see the tests for more.
**Limitations and/or future work:**
* Doesn't work if the LHS can have side-effects at all, for example by being a function call
* Only works for exactly two comparison expressions, so `x > y && x > z && x < w` won't get checked
* Doesn't check for comparison expressions combined with `||`. Very similar logic could be applied there.
changelog: New lints [`impossible_comparisons`] and [`redundant_comparisons`]
