`match_impl` has two call sites. For one of them (within `rematch_impl`)
the fast reject test isn't necessary, because any rejection would
represent a compiler bug.
This commit moves the fast reject test to the other `match_impl` call
site, in `assemble_candidates_from_impls`. This lets us move the fast
reject test outside the `probe` call in that function. This avoids the
taking of useless snapshots when the fast reject test succeeds, which
gives a performance win when compiling the `bitmaps` and `nalgebra`
crates.
Co-authored-by: name <n.nethercote@gmail.com>
Add aliases for `current_dir`
Aliases were added for the equivalent C/C++ APIs for POSIX and Windows. Also, I added one for `pwd` which users may be more familiar with, from the command line.
Introduce stricter checks for might_permit_raw_init under a debug flag
This is intended to be a version of the strict checks tried out in #79296, but also checking number validity (under the assumption that `let _ = std::mem::uninitialized::<u32>()` is UB, which seems to be what https://github.com/rust-lang/unsafe-code-guidelines/issues/71 is leaning towards.)
Change orderings of `Debug` for the Atomic types to `Relaxed`.
This reduces synchronization between threads when debugging the atomic types. Reducing the synchronization means that executions with and without the debug calls will be more consistent, making it easier to debug.
We discussed this on the Rust Community Discord with `@ibraheemdev` before.
Make `Lazy*<T>` types in `rustc_metadata` not care about lifetimes until decode
This allows us to remove the `'tcx` lifetime from `CrateRoot`. This is necessary because of #97287, which makes the `'tcx` lifetime on `Ty` invariant instead of covariant, so [this hack](0a437b2ca0/compiler/rustc_metadata/src/rmeta/decoder.rs (L89-92)) no longer holds under that PR.
Introduces a trait called `ParameterizedOverTcx` which has a generic associated type that allows a type to be parameterized over that lifetime. This means we can decode, for example, `Lazy<Ty<'static>>` into any `Ty<'tcx>` depending on the `TyCtxt<'tcx>` we pass into the decode function.
Make weird name lints trigger behind cfg_attr
The weird name lints (`unknown_lints`, `renamed_and_removed_lints`), the lints that lint the linting, were previously not firing for lint level declarations behind `cfg_attr`, as they were only running before expansion.
Now, this will give a `unknown_lints` warning:
```Rust
#[cfg_attr(all(), allow(this_lint_does_not_exist))]
fn foo() {}
```
Lint level declarations behind a `cfg_attr` whose condition is not applying are still ignored. So this still won't give a warning:
```Rust
#[cfg_attr(any(), allow(this_lint_does_not_exist))]
fn foo() {}
```
Furthermore, this PR also makes the weird name lints respect level delcarations for *them* that were hidden by `cfg_attr`, making them consistent to other lints. So this will now not issue a warning:
```Rust
#[cfg_attr(all(), allow(unknown_lints))]
mod foo {
#[allow(does_not_exist)]
fn foo() {
}
}
```
Fixes#97094
Ensure all error checking for `#[debugger_visualizer]` is done up front and not when the `debugger_visualizer` query is run.
Clean up potential ODR violations when embedding pretty printers into the `__rustc_debug_gdb_scripts_section__` section.
Respond to PR comments and update documentation.
Rollup of 4 pull requests
Successful merges:
- #97288 (Lifetime variance fixes for rustdoc)
- #97298 (Parse expression after `else` as a condition if followed by `{`)
- #97308 (Stabilize `cell_filter_map`)
- #97321 (explain how to turn integers into fn ptrs)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Use new typed Fluent identifiers for the "missing type parameters"
diagnostic in the typeck crate which was manually creating
`DiagnosticMessage`s previously.
Signed-off-by: David Wood <david.wood@huawei.com>
Adds a new `fluent_messages` macro which performs compile-time
validation of the compiler's Fluent resources (i.e. that the resources
parse and don't multiply define the same messages) and generates
constants that make using those messages in diagnostics more ergonomic.
For example, given the following invocation of the macro..
```ignore (rust)
fluent_messages! {
typeck => "./typeck.ftl",
}
```
..where `typeck.ftl` has the following contents..
```fluent
typeck-field-multiply-specified-in-initializer =
field `{$ident}` specified more than once
.label = used more than once
.label-previous-use = first use of `{$ident}`
```
...then the macro parse the Fluent resource, emitting a diagnostic if it
fails to do so, and will generate the following code:
```ignore (rust)
pub static DEFAULT_LOCALE_RESOURCES: &'static [&'static str] = &[
include_str!("./typeck.ftl"),
];
mod fluent_generated {
mod typeck {
pub const field_multiply_specified_in_initializer: DiagnosticMessage =
DiagnosticMessage::fluent("typeck-field-multiply-specified-in-initializer");
pub const field_multiply_specified_in_initializer_label_previous_use: DiagnosticMessage =
DiagnosticMessage::fluent_attr(
"typeck-field-multiply-specified-in-initializer",
"previous-use-label"
);
}
}
```
When emitting a diagnostic, the generated constants can be used as
follows:
```ignore (rust)
let mut err = sess.struct_span_err(
span,
fluent::typeck::field_multiply_specified_in_initializer
);
err.span_default_label(span);
err.span_label(
previous_use_span,
fluent::typeck::field_multiply_specified_in_initializer_label_previous_use
);
err.emit();
```
Signed-off-by: David Wood <david.wood@huawei.com>
With `ignore (rust)` rather than `ignore (pseudo-Rust)` my editor
highlights the code in the block, which is nicer.
Signed-off-by: David Wood <david.wood@huawei.com>
Previously, we were emitting weird name lints (for renamed or unknown lints)
before expansion, most importantly before cfg expansion.
This meant that the weird name lints would not fire
for lint attributes hidden inside cfg_attr. The same applied
for lint level specifications of those lints.
By moving the lints for the lint names to the post-expansion
phase, these issues are resolved.
explain how to turn integers into fn ptrs
(with an intermediate raw ptr, not a direct transmute)
Direct int2ptr transmute, under the semantics I am imagining, will produce a ptr with "invalid" provenance that is invalid to deref or call. We cannot give it the same semantics as int2ptr casts since those do [something complicated](https://www.ralfj.de/blog/2022/04/11/provenance-exposed.html).
To my great surprise, that is already what the example in the `transmute` docs does. :) I still added a comment to say that that part is important, and I added a section explicitly talking about this to the `fn()` type docs.
With https://github.com/rust-lang/miri/pull/2151, Miri will start complaining about direct int-to-fnptr transmutes (in the sense that it is UB to call the resulting pointer).
