Move the cast_float_to_int fallback code to GCC
Now that we require at least LLVM 13, that codegen backend is always
using its intrinsic `fptosi.sat` and `fptoui.sat` conversions, so it
doesn't need the manual implementation. However, the GCC backend still
needs it, so we can move all of that code down there.
Attempt to normalize `FnDef` signature in `InferCtxt::cmp`
Stashes a normalization callback in `InferCtxt` so that the signature we get from `tcx.fn_sig(..).subst(..)` in `InferCtxt::cmp` can be properly normalized, since we cannot expect for it to have normalized types since it comes straight from astconv.
This is kind of a hack, but I will say that `@jyn514` found the fact that we present unnormalized types to be very confusing in real life code, and I agree with that feeling. Though altogether I am still a bit unsure about whether this PR is worth the effort, so I'm open to alternatives and/or just closing it outright.
On the other hand, this isn't a ridiculously heavy implementation anyways -- it's less than a hundred lines of changes, and half of that is just miscellaneous cleanup.
This is stacked onto #100471 which is basically unrelated, and it can be rebased off of that when that lands or if needed.
---
The code:
```rust
trait Foo { type Bar; }
impl<T> Foo for T {
type Bar = i32;
}
fn foo<T>(_: <T as Foo>::Bar) {}
fn needs_i32_ref_fn(f: fn(&'static i32)) {}
fn main() {
needs_i32_ref_fn(foo::<()>);
}
```
Before:
```
= note: expected fn pointer `fn(&'static i32)`
found fn item `fn(<() as Foo>::Bar) {foo::<()>}`
```
After:
```
= note: expected fn pointer `fn(&'static i32)`
found fn item `fn(i32) {foo::<()>}`
```
Do not leak type variables from opaque type relation
The "root cause" is that we call `InferCtxt::resolve_vars_if_possible` (3d9dd681f5) on the types we get back in `TypeError::Sorts` since I added a call to it in `InferCtxt::same_type_modulo_infer`. However if this `TypeError` comes from a `InferCtxt::commit_if_ok`, then it may reference type variables that do not exist anymore, which is problematic.
We avoid this by substituting the `TypeError` with the types we had before being generalized while handling opaques.
This is kinda gross, and I feel like we can get the same issue from other places where we generalize type/const inference variables. Maybe not? I don't know.
Fixes#99914Fixes#99970Fixes#100463
Display raw pointer as *{mut,const} T instead of *-ptr in errors
The `*-ptr` is rather confusing, and we have the full information for properly displaying the information.
Rollup of 9 pull requests
Successful merges:
- #95376 (Add `vec::Drain{,Filter}::keep_rest`)
- #100092 (Fall back when relating two opaques by substs in MIR typeck)
- #101019 (Suggest returning closure as `impl Fn`)
- #101022 (Erase late bound regions before comparing types in `suggest_dereferences`)
- #101101 (interpret: make read-pointer-as-bytes a CTFE-only error with extra information)
- #101123 (Remove `register_attr` feature)
- #101175 (Don't --bless in pre-push hook)
- #101176 (rustdoc: remove unused CSS selectors for `.table-display`)
- #101180 (Add another MaybeUninit array test with const)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
rustdoc: remove unused CSS selectors for `.table-display`
This class was added to support the function signature [src] lockup. That lockup was changed in 34bd2b845b to use flexbox instead, leaving these selectors unused.
Continuation of #101046
Don't --bless in pre-push hook
Running with --bless causes the push to succeed if there are fixable
formatting changes, but the changes don't make it into the push.
We should have the user rerun with --bless (or x.py fmt) and commit the
changes themselves (they might want to amend a particular commit, for
instance).
interpret: make read-pointer-as-bytes a CTFE-only error with extra information
Next step in the reaction to https://github.com/rust-lang/rust/issues/99923. Also teaches Miri to implicitly strip provenance in more situations when transmuting pointers to integers, which fixes https://github.com/rust-lang/miri/issues/2456.
Pointer-to-int transmutation during CTFE now produces a message like this:
```
= help: this code performed an operation that depends on the underlying bytes representing a pointer
= help: the absolute address of a pointer is not known at compile-time, so such operations are not supported
```
r? ``@oli-obk``
Fall back when relating two opaques by substs in MIR typeck
This is certainly _one_ way to fix#100075. Not really confident it's the _best_ way to do it, though.
The root cause of this issue is that during MIR type-check, we end up trying to equate an opaque against the same opaque def-id but with different substs. Because of the way that we replace RPITs during (HIR) typeck with an inference variable, we don't end up emitting a type-checking error, so the delayed MIR bug causes an ICE.
See the `src/test/ui/impl-trait/issue-100075-2.rs` test below to make that clear -- in that example, we try to equate `{impl Sized} substs=[T]` and `{impl Sized} substs=[Option<T>]`, which causes an ICE. This new logic will instead cause us to infer `{impl Sized} substs=[Option<T>]` as the hidden type for `{impl Sized} substs=[T]`, which causes a proper error to be emitted later on when we check that an opaque isn't recursive.
I'm open to closing this in favor of something else. Ideally we'd fix this in typeck, but the thing we do to ensure backwards compatibility with weird RPIT cases makes that difficult. Also open to discussing this further.
Add `vec::Drain{,Filter}::keep_rest`
This PR adds `keep_rest` methods to `vec::Drain` and `vec::DrainFilter` under `drain_keep_rest` feature gate:
```rust
// mod alloc::vec
impl<T, A: Allocator> Drain<'_, T, A> {
pub fn keep_rest(self);
}
impl<T, F, A: Allocator> DrainFilter<'_, T, F, A>
where
F: FnMut(&mut T) -> bool,
{
pub fn keep_rest(self);
}
```
Both these methods cancel draining of elements that were not yet yielded from the iterators. While this needs more testing & documentation, I want at least start the discussion. This may be a potential way out of the "should `DrainFilter` exhaust itself on drop?" argument.
Revert let_chains stabilization
This is the revert against master, the beta revert was already done in #100538.
Bumps the stage0 compiler which already has it reverted.
This class was added to support the function signature [src] lockup. That
lockup was changed in 34bd2b845b to use flexbox
instead, leaving these selectors unused.
Running with --bless causes the push to succeed if there are fixable
formatting changes, but the changes don't make it into the push.
We should have the user rerun with --bless (or x.py fmt) and commit the
changes themselves (they might want to amend a particular commit, for
instance).
Rollup of 7 pull requests
Successful merges:
- #100898 (Do not report too many expr field candidates)
- #101056 (Add the syntax of references to their documentation summary.)
- #101106 (Rustdoc-Json: Retain Stripped Modules when they are imported, not when they have items)
- #101131 (CTFE: exposing pointers and calling extern fn is just impossible)
- #101141 (Simplify `get_trait_ref` fn used for `virtual_function_elimination`)
- #101146 (Various changes to logging of borrowck-related code)
- #101156 (Remove `Sync` requirement from lint pass objects)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Remove `Sync` requirement from lint pass objects
This is blocking the clippy sync (#101140). One of the lint passes contains a `Cell` in order to make lifetimes work. It could be worked around, but this is the easier change to make if there are no objections.
Rational for removing the requirement
* All lint pass methods take `&mut self` arguments.
* Many passes depend on running is visitor order.
* Lint passes are created on demand so they're only ever stored in a local.
* `Send` is enough to lint different passes in parallel.
`LintStore` remains `Sync` with this. The constructor functions it contains still maintain their `Sync` requirement.
r? rust-lang/compiler
Simplify `get_trait_ref` fn used for `virtual_function_elimination`
1. The name `get_trait_ref` is misleading, so I renamed it to something more like `expect_...` because it ICEs if used incorrectly.
2. No need to manually go through the existential trait refs, we already have `.principal()` for that.
CTFE: exposing pointers and calling extern fn is just impossible
The remaining "needs RFC" errors are just needlessly confusing, I think -- time to get rid of that error variant. They are anyway only reachable with miri-unleashed (if at all).
r? `@oli-obk`
Add the syntax of references to their documentation summary.
Without this change, in <https://doc.rust-lang.org/1.63.0/std/#primitives>, `reference` is the only entry in that list which does not contain the syntax by which the type is named in source code. With this change, it contains them, in roughly the same way as the `pointer` entry does.
Do not report too many expr field candidates
When considering "this expressions' field has a {field/method}" suggestions:
1. Don't report methods that are out of scope
2. Use `span_suggestions` instead of reporting each field candidate, which caps the number of suggestions to 4
4. Blacklist some common traits like `Clone` and `Deref`
Fixes#100894
Separate CountIsStar from CountIsParam in rustc_parse_format.
`rustc_parse_format`'s parser would result in the exact same output for `{:.*}` and `{:.0$}`, making it hard for diagnostics to handle these cases properly.
This splits those cases by adding a new `CountIsStar` enum variant.
This fixes#100995
Prerequisite for https://github.com/rust-lang/rust/pull/100996
Make use of `[wrapping_]byte_{add,sub}`
These new methods trivially replace old `.cast().wrapping_offset().cast()` & similar code.
Note that [`arith_offset`](https://doc.rust-lang.org/std/intrinsics/fn.arith_offset.html) and `wrapping_offset` are the same thing.
r? ``@scottmcm``
_split off from #100746_
Stabilize `std::io::read_to_string`
Closes#80218. 🎉
This PR stabilizes the `std::io::read_to_string` function, with the following public API:
```rust
pub fn read_to_string<R: Read>(reader: R) -> Result<String>;
```
It's analogous to `std::fs::read_to_string` for files, but it works on anything that implements `io::Read`, including `io::stdin()`.
See the tracking issue (#80218) or documentation for details.
remove an ineffective check in const_prop
Based on https://github.com/rust-lang/rust/pull/100043, only the last two commits are new.
ConstProp has a special check when reading from a local that prevents reading uninit locals. However, if that local flows into `force_allocation`, then no check fires and evaluation proceeds. So this check is not really effective at preventing accesses to uninit locals.
With https://github.com/rust-lang/rust/pull/100043, `read_immediate` and friends always fail when reading uninit locals, so I don't see why ConstProp would need a separate check. Thus I propose we remove it. This is needed to be able to do https://github.com/rust-lang/rust/pull/100085.
Remove separate indexing of early-bound regions
~Based on https://github.com/rust-lang/rust/pull/99728.~
This PR copies some modifications from https://github.com/rust-lang/rust/pull/97839 around object lifetime defaults.
These modifications allow to stop counting generic parameters during lifetime resolution, and rely on the indexing given by `rustc_typeck::collect`.
Add a `File::create_new` constructor
We have `File::create` for creating a file or opening an existing file,
but the secure way to guarantee creating a new file requires a longhand
invocation via `OpenOptions`.
Add `File::create_new` to handle this case, to make it easier for people
to do secure file creation.
Use posix_spawn for absolute paths on macOS
Currently, on macOS, Rust never uses the fast posix_spawn path if a
directory change is requested, due to a bug in Apple's libc. However, the
bug is only triggered if the program is a relative path.
This PR makes it so that the fast path continues to work if the program
is an absolute path or a lone filename.
This was an alternative proposed in https://github.com/rust-lang/rust/pull/80537#issue-776674009, and it makes a measurable performance difference in some of my code that spawns thousands of processes.
5 commits in 6da726708a4406f31f996d813790818dce837161..4ed54cecce3ce9ab6ff058781f4c8a500ee6b8b5
2022-08-23 21:39:56 +0000 to 2022-08-27 18:41:39 +0000
- doc: pause, for readability (rust-lang/cargo#11027)
- Bump git2 to 0.15 and libgit2-sys to 0.14 (rust-lang/cargo#11004)
- Fix typo (rust-lang/cargo#11025)
- Update cargo-toml-vs-cargo-lock.md (rust-lang/cargo#11021)
- Apply GitHub fast path even for partial hashes (rust-lang/cargo#10807)
[rustdoc] Remove Attrs type alias
When working on https://github.com/rust-lang/rust/pull/101006, I was quite confused because of this type alias as I'm used to having rustdoc types into `clean/types.rs`. Anyway, considering how few uses of it we have, I simply removed it.
r? `````@notriddle`````
Use the declaration's SourceInfo for FnEntry retags, not the outermost
This addresses a long-standing `// FIXME` in the pass that adds retags.
The changes to Miri's UI tests will look like this:
```
--> $DIR/aliasing_mut1.rs:LL:CC
|
LL | pub fn safe(_x: &mut i32, _y: &mut i32) {}
< | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not granting access to tag <TAG> because incompatible item [Unique for <TAG>] is protected by call ID
> | ^^ not granting access to tag <TAG> because incompatible item [Unique for <TAG>] is protected by call ID
|
```
r? ````@RalfJung````
