Reduce monomorphisation bloat in small_c_string
This is a code path usually next to an FFI call, so taking the `dyn` slowdown for the 1159 llvm-line (fat lto, codegen-units 1, release build) drop in my testing program [t2fanrd](https://github.com/GnomedDev/t2fanrd) is worth it imo.
Tracking import use types for more accurate redundant import checking
fixes#117448
By tracking import use types to check whether it is scope uses or the other situations like module-relative uses, we can do more accurate redundant import checking.
For example unnecessary imports in std::prelude that can be eliminated:
```rust
use std::option::Option::Some;//~ WARNING the item `Some` is imported redundantly
use std::option::Option::None; //~ WARNING the item `None` is imported redundantly
```
fixes#117448
For example unnecessary imports in std::prelude that can be eliminated:
```rust
use std::option::Option::Some;//~ WARNING the item `Some` is imported redundantly
use std::option::Option::None; //~ WARNING the item `None` is imported redundantly
```
errors: only eagerly translate subdiagnostics
Subdiagnostics don't need to be lazily translated, they can always be eagerly translated. Eager translation is slightly more complex as we need to have a `DiagCtxt` available to perform the translation, which involves slightly more threading of that context.
This slight increase in complexity should enable later simplifications - like passing `DiagCtxt` into `AddToDiagnostic` and moving Fluent messages into the diagnostic structs rather than having them in separate files (working on that was what led to this change).
r? ```@nnethercote```
tidy: reduce allocs
this reduces allocs in tidy from (dhat output)
```
==31349== Total: 1,365,199,543 bytes in 4,774,213 blocks
==31349== At t-gmax: 10,975,708 bytes in 66,093 blocks
==31349== At t-end: 2,880,947 bytes in 12,332 blocks
==31349== Reads: 5,210,008,956 bytes
==31349== Writes: 1,280,920,127 bytes
```
to
```
==66633== Total: 791,565,538 bytes in 3,503,144 blocks
==66633== At t-gmax: 10,914,511 bytes in 65,997 blocks
==66633== At t-end: 395,531 bytes in 941 blocks
==66633== Reads: 4,249,388,949 bytes
==66633== Writes: 814,119,580 bytes
```
<del>by wrapping regex and updating `ignore` (effect probably not only from `ignore`, didn't measured)</del>
also moves one more regex into `Lazy` to reduce regex rebuilds.
yes, once_cell better, but ...
this reduces from
==31349== Total: 1,365,199,543 bytes in 4,774,213 blocks
==31349== At t-gmax: 10,975,708 bytes in 66,093 blocks
==31349== At t-end: 2,880,947 bytes in 12,332 blocks
==31349== Reads: 5,210,008,956 bytes
==31349== Writes: 1,280,920,127 bytes
to
==47796== Total: 821,467,407 bytes in 3,955,595 blocks
==47796== At t-gmax: 10,976,209 bytes in 66,100 blocks
==47796== At t-end: 2,944,016 bytes in 12,490 blocks
==47796== Reads: 4,788,959,023 bytes
==47796== Writes: 975,493,639 bytes
miropt-test-tools: remove regex usage
this removes regex usage and slightly refactors ext stripping in one case
This fixes the issue wherein the lint didn't fire for promoteds
in the case of SHL/SHR operators in non-optimized builds
and all arithmetic operators in optimized builds
Implement intrinsics with fallback bodies
fixes#93145 (though we can port many more intrinsics)
cc #63585
The way this works is that the backend logic for generating custom code for intrinsics has been made fallible. The only failure path is "this intrinsic is unknown". The `Instance` (that was `InstanceDef::Intrinsic`) then gets converted to `InstanceDef::Item`, which represents the fallback body. A regular function call to that body is then codegenned. This is currently implemented for
* codegen_ssa (so llvm and gcc)
* codegen_cranelift
other backends will need to adjust, but they can just keep doing what they were doing if they prefer (though adding new intrinsics to the compiler will then require them to implement them, instead of getting the fallback body).
cc `@scottmcm` `@WaffleLapkin`
### todo
* [ ] miri support
* [x] default intrinsic name to name of function instead of requiring it to be specified in attribute
* [x] make sure that the bodies are always available (must be collected for metadata)
Add an ErrorGuaranteed to ast::TyKind::Err (attempt 2)
This makes it more like `hir::TyKind::Err`, and avoids a `has_errors` assertion in `LoweringContext::lower_ty_direct`.
r? ```@oli-obk```
Add `ErrorGuaranteed` to `ast::LitKind::Err`, `token::LitKind::Err`.
Similar to recent work doing the same for `ExprKind::Err` (#120586) and `TyKind::Err` (#121109).
r? `@oli-obk`
Fix msg for verbose suggestions with confusable capitalization
When encountering a verbose/multipart suggestion that has changes that are only caused by different capitalization of ASCII letters that have little differenciation, expand the message to highlight that fact (like we already do for inline suggestions).
The logic to do this was already present, but implemented incorrectly.
Subdiagnostics don't need to be lazily translated, they can always be
eagerly translated. Eager translation is slightly more complex as we need
to have a `DiagCtxt` available to perform the translation, which involves
slightly more threading of that context.
This slight increase in complexity should enable later simplifications -
like passing `DiagCtxt` into `AddToDiagnostic` and moving Fluent messages
into the diagnostic structs rather than having them in separate files
(working on that was what led to this change).
Signed-off-by: David Wood <david@davidtw.co>
Store static initializers in metadata instead of the MIR of statics.
This means that adding generic statics would be even more difficult, as we can't evaluate statics from other crates anymore, but the subtle issue I have encountered make me think that having this be an explicit problem is better.
The issue is that
```rust
static mut FOO: &mut u32 = &mut 42;
static mut BAR = unsafe { FOO };
```
gets different allocations, instead of referring to the same one. This is also true for non-static mut, but promotion makes `static FOO: &u32 = &42;` annoying to demo.
Fixes https://github.com/rust-lang/rust/issues/61345
## Why is this being done?
In order to ensure all crates see the same nested allocations (which is the last issue that needs fixing before we can stabilize [`const_mut_refs`](https://github.com/rust-lang/rust/issues/57349)), I am working on creating anonymous (from the Rust side, to LLVM it's like a regular static item) static items for the nested allocations in a static. If we evaluate the static item in a downstream crate again, we will end up duplicating its nested allocations (and in some cases, like the `match` case, even duplicate the main allocation).
Make contributing to windows bindings easier
This PR does three things:
- Automatically sorts bindings so contributors don't have to. I should have done this to begin with but was lazy.
- Renames `windows_sys.lst` to `bindings.txt`. This [matches the windows-rs repository](8e71051ea8/crates/tools/sys/bindings.txt) (and repos that copy it). I believe consistency with other projects helps get people orientated.
- Adds a `README.md` file explaining what this is about and how to add bindings. This has the benefit of being directly editable and it's rendered when viewed online. Also people are understandably jumping right into the `windows_sys.rs` file via ripgrep or github search and so missing that it's generated. A `README.md` alongside it is at least slightly more obvious in that case. There is still a small note at the top of `windows_sys` in case people do read from the beginning.
None of this has any impact on the actual code generated. It's purely to make the new contributors workflow a bit nicer.
This mostly works well, and eliminates a couple of delayed bugs.
One annoying thing is that we should really also add an
`ErrorGuaranteed` to `proc_macro::bridge::LitKind::Err`. But that's
difficult because `proc_macro` doesn't have access to `ErrorGuaranteed`,
so we have to fake it.
This makes it more like `hir::TyKind::Err`, and avoids a
`span_delayed_bug` call in `LoweringContext::lower_ty_direct`.
It also requires adding `ast::TyKind::Dummy`, now that
`ast::TyKind::Err` can't be used for that purpose in the absence of an
error emission.
There are a couple of cases that aren't as neat as I would have liked,
marked with `FIXME` comments.
When encountering a verbose/multipart suggestion that has changes
that are only caused by different capitalization of ASCII letters that have
little differenciation, expand the message to highlight that fact (like we
already do for inline suggestions).
The logic to do this was already present, but implemented incorrectly.
Format `async` trait bounds in rustfmt
r? `@ytmimi` or `@calebcartwright`
This PR opts to do formatting in the rust-lang/rust tree because otherwise we'd have to wait until a full sync, and rustfmt is currently totally removing the `async` keyword.
cc https://github.com/rust-lang/rustfmt/issues/6070
