libtest: use binary search for --exact test filtering
When `--exact` is passed in, use binary search for O(f log n) lookups instead of an O(n) linear scan, under the assumption that f << n (which is true for the most relevant cases).
This is important for Miri, where the interpreted execution makes the linear scan very expensive.
I measured this against a repo with 1000 empty tests, running `cargo +stage1 miri nextest run test_00` (100 tests) under hyperfine:
* Before (linear scan): 49.7s ± 0.6s
* After (binary search): 41.9s ± 0.2s (-15.7%)
I also tried a few other variations (particularly swapping matching tests to the front of the list + truncating the list), but the index + swap_remove approach proved to be the fastest.
Questions:
- [ ] To be conservative, I've assumed that test_main can potentially receive an unsorted list of tests. Is this assumption correct?
Start using pattern types in libcore
cc rust-lang/rust#135996
Replaces the innards of `NonNull` with `*const T is !null`.
This does affect LLVM's optimizations, as now reading the field preserves the metadata that the field is not null, and transmuting to another type (e.g. just a raw pointer), will also preserve that information for optimizations. This can cause LLVM opts to do more work, but it's not guaranteed to produce better machine code.
Once we also remove all uses of rustc_layout_scalar_range_start from rustc itself, we can remove the support for that attribute entirely and handle all such needs via pattern types
Introduce a `#[diagnostic::on_unknown]` attribute
This PR introduces a `#[diagnostic::on_unknown]` attribute that allows crate authors to customize the error messages emitted by unresolved imports. The main usecase for this is using this attribute as part of a proc macro that expects a certain external module structure to exist or certain dependencies to be there.
For me personally the motivating use-case are several derives in diesel, that expect to refer to a `tabe` module. That is done either implicitly (via the name of the type with the derive) or explicitly by the user. This attribute would allow us to improve the error message in both cases:
* For the implicit case we could explicity call out our assumptions (turning the name into lower case, adding an `s` in the end)
+ point to the explicit variant as alternative
* For the explicit variant we would add additional notes to tell the user why this is happening and what they should look for to fix the problem (be more explicit about certain diesel specific assumptions of the module structure)
I assume that similar use-cases exist for other proc-macros as well, therefore I decided to put in the work implementing this new attribute. I would also assume that this is likely not useful for std-lib internal usage.
related rust-lang/rust#152900 and rust-lang/rust#128674
This PR introduces a `#[diagnostic::on_unknown_item]` attribute that
allows crate authors to customize the error messages emitted by
unresolved imports. The main usecase for this is using this attribute as
part of a proc macro that expects a certain external module structure to
exist or certain dependencies to be there.
For me personally the motivating use-case are several derives in diesel,
that expect to refer to a `tabe` module. That is done either
implicitly (via the name of the type with the derive) or explicitly by
the user. This attribute would allow us to improve the error message in
both cases:
* For the implicit case we could explicity call out our
assumptions (turning the name into lower case, adding an `s` in the end)
+ point to the explicit variant as alternative
* For the explicit variant we would add additional notes to tell the
user why this is happening and what they should look for to fix the
problem (be more explicit about certain diesel specific assumptions of
the module structure)
I assume that similar use-cases exist for other proc-macros as well,
therefore I decided to put in the work implementing this new attribute.
I would also assume that this is likely not useful for std-lib internal
usage.
Rollup of 6 pull requests
Successful merges:
- rust-lang/rust#154912 (Remove `BuiltinLintDiag`)
- rust-lang/rust#154598 (test `#[naked]` with `#[link_section = "..."]` on windows)
- rust-lang/rust#154719 (Hexagon inline asm: add reg_pair, vreg, vreg_pair, and qreg register classes)
- rust-lang/rust#154057 (Parenthesize block-like expressions in index base of pretty printer)
- rust-lang/rust#154893 (make `expected_literal` positive)
- rust-lang/rust#155002 (Clarify that `core::range` ranges do not have special syntax)
Use fine grained component-wise span tracking in use trees
This often produces nicer spans and even doesn't need a Span field anymore (not that I expect the unused field to affect any perf, but still neat).
The test array is sorted by name at compile time. When `--exact` is
passed in, use binary search for O(f log n) lookups instead of an O(n)
linear scan, under the assumption that f << n (which is true for the
most relevant cases).
This is important for Miri, where the interpreted execution makes the
linear scan very expensive.
I measured this against a repo with 1000 empty tests, running
`cargo +stage1 miri nextest run test_00` (100 tests) under hyperfine:
* Before (linear scan): 49.7s ± 0.6s
* After (binary search): 41.9s ± 0.2s (-15.7%)
I also tried a few other variations (particularly swapping matching tests to the front of the list + truncating the list), but the index + swap_remove approach proved to be the fastest.
Questions:
- [ ] To be conservative, I've assumed that test_main can potentially receive an unsorted list of tests. Is this assumption correct?
Allow applying autodiff macros to trait functions.
It will use enzyme to generate a default derivative implementation, which can be overwritten by the user.
closes: https://github.com/rust-lang/rust/issues/153329
r? @JonathanBrouwer
Allow passing `expr` metavariable as `cfg` predicate
This PR allows expanding `expr` metavariables inside the configuration predicates of `cfg` and `cfg_attr` invocations.
For example, the following code will now compile:
```rust
macro_rules! mac {
($e:expr) => {
#[cfg_attr($e, inline)]
#[cfg($e)]
fn func() {}
#[cfg(not($e))]
fn func() {
panic!()
}
}
}
mac!(any(unix, feature = "foo"));
```
There is currently no `macro_rules` fragment specifier that can represent all valid `cfg` predicates. `meta` comes closest, but excludes `true` and `false`. By fixing that, this change makes it easier to write declarative macros that parse `cfg` or `cfg_attr` invocations, for example https://github.com/rust-lang/rust/pull/146281/.
@rustbot label T-lang needs-fcp A-attributes A-cfg A-macros
fix: don't suggest replacing `env!("CARGO_BIN_NAME")` with itself
Some environment variables (e.g. `CARGO_BIN_NAME`) are only available for some targets ([Cargo Targets](https://doc.rust-lang.org/cargo/reference/cargo-targets.html), [§ Environment variables Cargo sets for crates](https://doc.rust-lang.org/cargo/reference/environment-variables.html#environment-variables-cargo-sets-for-crates)), and the current diagnostic when copy-pasting code from a binary to a library is kinda confusing:
```rs
const _: &str = env!("CARGO_BIN_NAME");
```
Before:
```
error: environment variable `CARGO_BIN_NAME` not defined at compile time
--> lib.rs:1:17
|
1 | const _: &str = env!("CARGO_BIN_NAME");
| ^^^^^^^^^^^^^^^^^^^^^^
|
= help: there is a similar Cargo environment variable: `CARGO_BIN_NAME`
```
After:
```
error: environment variable `CARGO_BIN_NAME` not defined at compile time
--> lib.rs:1:17
|
1 | const _: &str = env!("CARGO_BIN_NAME");
| ^^^^^^^^^^^^^^^^^^^^^^
|
= help: `CARGO_BIN_NAME` may not be available for the current Cargo target
= help: Cargo sets build script variables at run time. Use `std::env::var("CARGO_BIN_NAME")` instead
```
@rustbot label +T-compiler +A-diagnostics +D-confusing
It's defined in `rustc_span::source_map` which doesn't make any sense
because it has nothing to do with source maps. This commit moves it to
the crate root, a more sensible spot for something this basic.
fix autodiff parsing for non-trait impl
fixes: https://github.com/rust-lang/rust/issues/153322
@Sa4dUs Looks like we missed a case.
But also, going through the code, line 455 seems suspicious to me:
`Annotatable::AssocItem(d_fn, Impl { of_trait: false })`
Are we sure that this should always be an Impl, and never an impl of a trait?
r? @oli-obk
Re-add `#[inline]` to `Eq::assert_fields_are_eq`
Fixes a compile-time regression in https://github.com/rust-lang/rust/pull/149978: non-inline methods are generally codegen'd while inline methods are deferred (and this function should never be called, so deferring is the right choice).
r? JonathanBrouwer
CC @cyrgani
Fixes a compile-time regressions, non-inline methods are generally
codegen'd while inline methods are deferred (and this should never be
called, so deferring is the right choice).
Jonathan Brouwer