Avoid `Lrc<Box<dyn CodegenBackend>>`.
Because `Lrc<Box<T>>` is silly. (Clippy warns about `Rc<Box<T>>` and `Arc<Box<T>>`, and it would warn here if (a) we used Clippy with rustc, and (b) Clippy knew about `Lrc`.)
r? `@bjorn3`
Change comparsion for checking if number is negative to include 128
The last byte in Little-Endian representation of negative integers start at 128 (Ox80) till 255 (OxFF). The comparison before the fix didn't check for 128 which made is_negative variable as false.
Potentially fixes#15096
Added a test near positive extermes and two test near negative
extermes as well one for 0.
Added a test using the `as` cast and one with comparison with 0.
feature : assist delegate impl
This PR ( fixes#14386 ) introduces a new IDE assist that generates a trait impl for a struct that delegates a field. This is a draft because the current `ide_db::path_transform::PathTransform` produces some unwanted results when it deals with extern crates, an example of which I attach as a GIF.
GIFs :
1. A general case
2. A case where `ide_db::path_transform::PathTransform` fails to correctly resolve a property ( take `Allocator` as an example ) to its full path, thus causing an error to occur. ( Not to even mention that resolving this causes another error `use of unstable library feature 'allocator_api'` to occur
Inline before merging cgus
Because CGU merging relies on CGU sizes, but the CGU sizes before inlining aren't accurate.
This change doesn't have much effect on compile perf, but it makes follow-on changes that involve more sophisticated reasoning about CGU sizes much easier.
r? `@wesleywiser`
Reason: The last byte in Little Endian representation of negative
integers start at 128 (Ox80) till 255 (OxFF). The comparison before
the fix didn't check for 128 which made is_negative variable as false.
Rollup of 4 pull requests
Successful merges:
- #112876 (Don't substitute a GAT that has mismatched generics in `OpaqueTypeCollector`)
- #112906 (rustdoc: render the body of associated types before the where-clause)
- #112907 (Update cargo)
- #112908 (Print def_id on EarlyBoundRegion debug)
r? `@ghost`
`@rustbot` modify labels: rollup
Print def_id on EarlyBoundRegion debug
It's not the first time that I can't make sense out of the default debug print on `EarlyBoundRegion`. As I was working on #112682 I needed this.
I was doing some git archeology and found that we used to print everything dfbc9608ce/src/librustc/util/ppaux.rs (L425-L430) but we lost the ability in some refactor midway.
Don't substitute a GAT that has mismatched generics in `OpaqueTypeCollector`
Fixes#111828
I didn't put up minimized UI tests for #112510 or #112873 because they'd minimize to literally the same code, but with different substs on the trait/impl. I don't think that warrants duplicate tests given the nature of the fix.
r? `@oli-obk`
----
Side-note: I checked, and this isn't fixed by #112652 -- I think we discussed whether or not that PR fixed it either intentionally or by accident. The code here isn't really touched by that PR either as far as I can tell?
Also, sorry, did some other drive-bys. Hope it doesn't make rebasing #112652 too difficult 😅
[`get_unwrap`]: include a borrow in the suggestion if argument is not an integer literal
Fixes#9909
I have to say, I don't really understand what the previous logic was trying to do, but this fixes the linked bug.
It was checking if the argument passed to `.get()` can be parsed as a usize (i.e. if it's an integer literal, probably?), and if not, it wouldn't include a borrow? I don't know how we came to that conclusion, but that logic doesn't work:
```rs
let slice = &[1, 2];
let _r: &i32 = slice.get({ 1 }).unwrap();
// previous suggestion: slice[{ 1 }]
// the suggestion should be: &slice[{ 1 }]
```
Here the argument passed to it isn't an integer literal, but it should still include a borrow, because it would otherwise change the type from `&i32` to `i32`.
The exception is that if the parent of the `get().unwrap()` expr is a dereference or a method call or the like, we don't need an explicit borrow because it's automatically inserted by the compiler
changelog: [`get_unwrap`]: include a borrow in the suggestion if argument is not an integer literal
- Rename `create_size_estimate` as `compute_size_estimate`, because that
makes more sense for the second and subsequent calls for each CGU.
- Change `CodegenUnit::size_estimate` from `Option<usize>` to `usize`.
We can still assert that `compute_size_estimate` is called first.
- Move the size estimation for `place_mono_items` inside the function,
for consistency with `merge_codegen_units`.
The section as written did not cover all cases, and left some of them
implicit. Rewrite it to systematically cover all cases. Place examples
immediately following the corresponding case.
In the process, reorder to move the simplest cases first: start with
single-line and add progressively more line breaks.
This does not change the meaning of the section at all, and in
particular does not change the defined style for let-else statements.
Because `Lrc<Box<T>>` is silly. (Clippy warns about `Rc<Box<T>>` and
`Arc<Box<T>>`, and it would warn here if (a) we used Clippy with rustc,
and (b) Clippy knew about `Lrc`.)
The codegen main loop has two bools, `codegen_done` and
`codegen_aborted`. There are only three valid combinations: `(false,
false)`, `(true, false)`, `(true, true)`.
This commit replaces them with a single tri-state enum, which makes
things clearer.
Support Apple tvOS in libstd
This target has existed in the compiler for a while, was `no_std`-only previously (even requiring `#![feature(restricted_std)]`). Apple tvOS is essentially the same as iOS, down to using the same version numbering, so there's no reason for this to be a `no_std`-only target the way it is currently.
Not yet tested much (I have an Apple TV, but haven't tested that this can deploy and run programs on it, nor the simulator). Uses the implementation strategy as the watchOS support in https://github.com/rust-lang/rust/pull/98101 and etc. That is, no `std::os::` interfaces aside from those in `std::os::unix`.
Includes an update to libc in order to pull in https://github.com/rust-lang/libc/pull/2958.
Because CGU merging relies on CGU sizes, but the CGU sizes before
inlining aren't accurate.
This requires tweaking how the sizes are updated during merging: if CGU
A and B both have an inlined function F, then `size(A + B)` will be a
little less than `size(A) + size(B)`, because `A + B` will only have one
copy of F. Also, the minimum CGU size is increased because it now has to
account for inlined functions.
This change doesn't have much effect on compile perf, but it makes
follow-on changes that involve more sophisticated reasoning about CGU
sizes much easier.
`Message` is an enum with multiple variants. Four of those variants map
directly onto the four variants of `WorkItemResult`. This commit reduces
those four `Message` variants to a single variant containing a
`WorkItemResult`. This requires increasing `WorkItemResult`'s visibility
to `pub(crate)` visibility, but `WorkItem` and `Message` can also have
their visibility reduced to `pub(crate)`.
This change avoids some boilerplate enum translation code, and makes
`Message` easier to understand.
`Message` is an enum with multiple variants, for messages sent to the
coordinator thread. *Except* for `Message::CodegenItem`, which is
entirely disjoint, being for messages sent from the coordinator thread
to the main thread.
This commit move `Message::CodegenItem` into a separate type,
`CguMessage`, which makes the code much clearer.
Don't lint [`iter_nth_zero`] in `next`
Closes#9820
This also *slightlyy* modifies the output of `iter_nth`, as I noticed the types' names weren't in backticks
changelog: [`iter_nth_zero`]: No longer lints in implementations of `Iterator::next`
