Martin Geisler [Wed, 31 Aug 2022 08:35:36 +0000 (10:35 +0200)]
Link “? operator” to relevant chapter in The Book
Before, the text simply asked people to use a symbol which is hard to
search for. Now the text links back to the chapter on error
propagation in The Book. That should help people find the relevant
keywords for further searches.
bors [Wed, 31 Aug 2022 07:57:09 +0000 (07:57 +0000)]
Auto merge of #101225 - matthiaskrgr:rollup-9s1chas, r=matthiaskrgr
Rollup of 8 pull requests
Successful merges:
- #100970 (Allow deriving multipart suggestions)
- #100984 (Reinstate preloading of some dll imports)
- #101011 (Use getentropy when possible on all Apple platforms)
- #101025 (Add tier-3 support for powerpc64 and riscv64 openbsd)
- #101049 (Remove span fatal from ast lowering)
- #101100 (Make call suggestions more general and more accurate)
- #101171 (Fix UB from misalignment and provenance widening in `std::sys::windows`)
- #101185 (Tweak `WellFormedLoc`s a bit)
Matthias Krüger [Wed, 31 Aug 2022 05:58:01 +0000 (07:58 +0200)]
Rollup merge of #101171 - thomcc:fix-winfs-ub, r=ChrisDenton
Fix UB from misalignment and provenance widening in `std::sys::windows`
This fixes two types of UB:
1. Reading past the end of a reference in types like `&c::REPARSE_DATA_BUFFER` (see https://github.com/rust-lang/unsafe-code-guidelines/issues/256). This is fixed by using `addr_of!`. I think there are probably a couple more cases where we do this for other structures, and will look into it in a bit.
2. Failing to ensure that a `[u8; N]` on the stack is sufficiently aligned to convert to a `REPARSE_DATA_BUFFER`. ~~This was done by introducing a new `AlignedAs` struct that allows aligning one type to the alignment of another type. I expect there are other places where we have this issue too, or I wouldn't introduce this type, but will get to them after this lands.~~
~~Worth noting, it *is* implemented in a way that can cause problems depending on how we fix #81996, but this would be caught by the test I added (and presumably if we decide to fix that in a way that would break this code, we'd also introduce a `#[repr(simple)]` or `#[repr(linear)]` as a replacement for this usage of `#[repr(C)]`).~~
Edit: None of that is still in the code, I just went with a `Align8` since that's all we'll need for almost everything we want to call.
These are more or less "potential UB" since it's likely at the moment everything works fine, although the alignment not causing issues might just be down to luck (and x86 being forgiving).
~~NB: I've only ensured this check builds, but will run tests soon.~~ All tests pass, including stage2 compiler tests.
Matthias Krüger [Wed, 31 Aug 2022 05:58:00 +0000 (07:58 +0200)]
Rollup merge of #101100 - compiler-errors:generalize-call-suggestions, r=petrochenkov
Make call suggestions more general and more accurate
Cleans up some suggestions that have to do with adding `()` to make typeck happy.
1. Drive-by rename of `expr_t` to `base_ty` since it's the type of the `base_expr`
1. Autoderef until we get to a callable type in `suggest_fn_call`.
1. Don't erroneously suggest calling constructor when a method/field does not exist on it.
1. Suggest calling a method receiver if its function output has a method (e.g. `fn.method()` => `fn().method()`)
1. Extend call suggestions to type parameters, fn pointers, trait objects where possible
1. Suggest calling in operators too (fixes #101054)
1. Use `/* {ty} */` as argument placeholder instead of just `_`, which is confusing and makes suggestions look less like `if let` syntax.
Matthias Krüger [Wed, 31 Aug 2022 05:57:58 +0000 (07:57 +0200)]
Rollup merge of #101025 - semarie:openbsd-archs, r=petrochenkov
Add tier-3 support for powerpc64 and riscv64 openbsd
# powerpc64
- MCP for [powerpc64-unknown-openbsd tier-3 support](https://github.com/rust-lang/compiler-team/issues/551)
- only need to add spec definition in rustc_target
# riscv64
- MCP for [riscv64-unknown-openbsd tier-3 support](https://github.com/rust-lang/compiler-team/issues/552)
- add spec definition in rustc_target
- follow freebsd about avoiding linking with `libatomic`
Matthias Krüger [Wed, 31 Aug 2022 05:57:56 +0000 (07:57 +0200)]
Rollup merge of #101011 - BlackHoleFox:apple-random-improvements, r=thomcc
Use getentropy when possible on all Apple platforms
As the current code comments say, `SecRandomCopyBytes` is very heavyweight (regardless of purpose) compared to just asking the kernel directly for bytes from its own CSPRNG. We were not previously making an attempt to use the more efficient `getentropy` call on other Apple targets, instead solely using it on macOS. As the function is available on newer versions of Apple's different OSes, this changes the random filling to always attempt it first everywhere, only falling back to the less ideal alternatives after. This also cleans up the multiple Apple `imp` blocks into one.
It also should give a perf improvement, even if its likely unnoticeably small.
Refed XCode header for `getentropy` in the SDK:
```h
int getentropy(void* buffer, size_t size) __OSX_AVAILABLE(10.12) __IOS_AVAILABLE(10.0) __TVOS_AVAILABLE(10.0) __WATCHOS_AVAILABLE(3.0);
```
Matthias Krüger [Wed, 31 Aug 2022 05:57:55 +0000 (07:57 +0200)]
Rollup merge of #100984 - ChrisDenton:reinstate-init, r=Mark-Simulacrum
Reinstate preloading of some dll imports
I've now come around to the conclusion that there is a justification for pre-loading the synchronization functions `WaitOnAddress` and `WakeByAddressSingle`. I've found this to have a particularly impact in testing frameworks that may have short lived processes which immediately spawn lots of threads.
Also, because pre-main initializers imply a single-threaded environment, we can switch back to using relaxed atomics which might be a minor perf improvement on some platforms (though I doubt it's particularly notable).
r? ``@Mark-Simulacrum`` and sorry for the churn here.
For convenience I'll summarise previous issues with preloading and the solutions that are included in this PR (if any):
**Issue:** User pre-main initializers may be run before std's
**Solution:** The std now uses initializers that are guaranteed to run earlier than the old initializers. A note is also added that users should not copy std's behaviour if they want to ensure they run their initializers after std.
**Issue:** Miri does not understand pre-main initializers.
**Solution:** For miri only, run the function loading lazily instead.
**Issue:** We should ideally use `LoadLibrary` to get "api-ms-win-core-synch-l1-2-0". Only "ntdll" and "kernel32" are guaranteed to always be loaded.
**Solution:** None. We can't use `LoadLibrary` pre-main. However, in the past `GetModuleHandle` has always worked in practice so this should hopefully not be a problem.
If/when Windows 7 support is dropped, we can finally remove all this for good and just use normal imports.
Matthias Krüger [Wed, 31 Aug 2022 05:57:54 +0000 (07:57 +0200)]
Rollup merge of #100970 - Xiretza:derive-multipart-suggestion, r=davidtwco
Allow deriving multipart suggestions
This turned into a bit more of a rewrite than I was initially hoping for... Still, I think the `SessionSubdiagnostic` derive is a little cleaner overall now, and closer to the `SessionDiagnostic` derive to make future code sharing easier.
7 commits in 42ca0ef484fcc8437a0682cee23abe4b7c407d52..0a5421ceb238357b3634fb75234eba4d1dad643c
2022-08-12 21:52:02 -0400 to 2022-08-28 19:51:04 -0400
- Add a missing line generated by 'cargo new'
- Clarify ThreadPool-Worker analogy wording
- Fixed incorrect mutex lock usage
- Merge remote-tracking branch 'origin/pr/3314'
- Put interactive book notice in a blockquote box to draw attention to it
- Remove the word 'new' because someday it won't be new anymore
- Merge remote-tracking branch 'origin/pr/3304'
## rustc-dev-guide
27 commits in d3daa1f28e169087becbc5e2b49ac91ca0405a44..04892c1a6fc145602ac7367945fda9d4ee83c9fb
2022-08-13 10:00:38 +0900 to 2022-08-29 20:07:51 +0200
- Fix the link to `Parser` struct
- Remove a dangling link on "The `#[test]` attribute"
- Update the stabilization guide to refer to the new placeholder system
- Refine the lintstore section (rust-lang/rustc-dev-guide#1429)
- typo
- Updates text to refer to LLVM documentation.
- Updates LLVM prereqs since upgrade to C++17.
- we got 3 (rust-lang/rustc-dev-guide#1447)
- A few corrections
- Update some statements
- correct typo in parallel-rustc.md
- Correct some statements in parallel-rustc.md
- update parallel-rustc.md
- address review comment
- make date-check more easy to use
- update thir output (rust-lang/rustc-dev-guide#1445)
- do not offer option to run code (rust-lang/rustc-dev-guide#1442)
- fix quick-edit link (rust-lang/rustc-dev-guide#1441)
- Document changes introduced by kind-less SessionDiagnostics
- diagnostics: fix outdated use of string slugs (rust-lang/rustc-dev-guide#1436)
- Add missing lifetime (rust-lang/rustc-dev-guide#1439)
- more syntax fixes
- fix incorrect #[note] syntax
- Update slug style to use _ instead of - (rust-lang/rustc-dev-guide#1426)
- remove incorrect info (rust-lang/rustc-dev-guide#1435)
- fix lifetime name (rust-lang/rustc-dev-guide#1431)
- Update the date reference around Git submodule bug (rust-lang/rustc-dev-guide#1430)
Yuki Okushi [Tue, 30 Aug 2022 23:47:21 +0000 (08:47 +0900)]
Rollup merge of #101193 - thomcc:win-stdio-nozero, r=ChrisDenton
Avoid zeroing large stack buffers in stdio on Windows
Does what it says on the tin, using `[MaybeUninit<u16>; N]` instead of `[0u16; N]`. These buffers seem to be around 8kb, which is big enough that this is likely to be a very nice perf boost to stdio-heavy windows code.
r? ``@ChrisDenton``
*(Note: this PR also has a commit that adds windows to CI, but as it mentions I'll revert that after it comes out green -- I can only do a check build on the machine I'm typing this on)*
Yuki Okushi [Tue, 30 Aug 2022 23:47:18 +0000 (08:47 +0900)]
Rollup merge of #101088 - nicholasbishop:bishop-uefi-pdb, r=davidtwco
Set DebuginfoKind::Pdb in msvc_base
This PDB setting was added to `windows_msvc_base` in
https://github.com/rust-lang/rust/pull/98051. It's also needed for the
UEFI targets, and since `uefi_msvc_base` and `windows_msvc_base` are the
only things that inherit from `msvc_base`, just move the PDB setting up
to `mscv_base` to cover both.
Yuki Okushi [Tue, 30 Aug 2022 23:47:17 +0000 (08:47 +0900)]
Rollup merge of #100927 - andrewpollack:fuchsia-docs-rustup, r=tmandry
Adding new Fuchsia rustup docs... reworking walkthrough
Docs improvements:
* Adding new `rustup` target add for Fuchsia targets
* Reworking walkthrough to show directory building as it happens
* Reworking walkthrough to use `hello_fuchsia_pkg/` directory
bors [Tue, 30 Aug 2022 23:43:33 +0000 (23:43 +0000)]
Auto merge of #99102 - JakobDegen:reorder-generators, r=oli-obk
Rework definition of MIR phases to more closely reflect semantic concerns
Implements most of rust-lang/compiler-team#522 .
I tried my best to restrict this PR to the "core" parts of the MCP. In other words, this includes just enough changes to make the new definition of `MirPhase` make sense. That means there are a couple of FIXMEs lying around. Depending on what reviewers prefer, I can either fix them in this PR or send follow up PRs. There are also a couple other refactorings of the `rustc_mir_transform/src/lib.rs` file that I want to do in follow ups that I didn't leave explicit FIXMEs for.
Jhonny Bill Mena [Sun, 21 Aug 2022 04:38:23 +0000 (00:38 -0400)]
ADD - migrate InvalidTraitItem and AltInvalidTraitItem errors
Thought of doing this by having a struct and an enum with Default and Alt cases, but not sure if we wanted to have the text in code instead of having “demangling()” and “demangling-alt()” in the ftl file.
Don’t like the current way of having structs representing the same-ish and using long names to distinguish their expectations, instead of putting this in an enum and handling the different cases inside the type.
I am fine with whichever option the team prefers; also understand having them as separate structs keeps it simple.
bors [Tue, 30 Aug 2022 18:20:45 +0000 (18:20 +0000)]
Auto merge of #9373 - lukaslueg:result_large_err, r=Alexendoo
Initial implementation `result_large_err`
This is a shot at #6560, #4652, and #3884. The lint checks for `Result` being returned from functions/methods where the `Err` variant is larger than a configurable threshold (the default of which is 128 bytes). There has been some discussion around this, which I'll try to quickly summarize:
* A large `Err`-variant may force an equally large `Result` if `Err` is actually bigger than `Ok`.
* There is a cost involved in large `Result`, as LLVM may choose to `memcpy` them around above a certain size.
* We usually expect the `Err` variant to be seldomly used, but pay the cost every time.
* `Result` returned from library code has a high chance of bubbling up the call stack, getting stuffed into `MyLibError { IoError(std::io::Error), ParseError(parselib::Error), ...}`, exacerbating the problem.
This PR deliberately does not take into account comparing the `Ok` to the `Err` variant (e.g. a ratio, or one being larger than the other). Rather we choose an absolute threshold for `Err`'s size, above which we warn. The reason for this is that `Err`s probably get `map_err`'ed further up the call stack, and we can't draw conclusions from the ratio at the point where the `Result` is returned. A relative threshold would also be less predictable, while not accounting for the cost of LLVM being forced to generate less efficient code if the `Err`-variant is _large_ in absolute terms.
We lint private functions as well as public functions, as the perf-cost applies to in-crate code as well.
In order to account for type-parameters, I conjured up `fn approx_ty_size`. The function relies on `LateContext::layout_of` to compute the actual size, and in case of failure (e.g. due to generics) tries to come up with an "at least size". In the latter case, the size of obviously wrong, but the inspected size certainly can't be smaller than that. Please give the approach a heavy dose of review, as I'm not actually familiar with the type-system at all (read: I have no idea what I'm doing).
The approach does, however flimsy it is, allow us to successfully lint situations like
// We know `UnionError<T>` will be at least 512 bytes, no matter what `T` is
pub fn param_large_union<T: Copy>() -> Result<(), UnionError<T>> {
Ok(())
}
```
I've given some refactoring to `functions/result_unit_err.rs` to re-use some bits. This is also the groundwork for #6409
The default threshold is 128 because of https://github.com/rust-lang/rust-clippy/issues/4652#issue-505670554
`lintcheck` does not trigger this lint for a threshold of 128. It does warn for 64, though.
The suggestion currently is the following, which is just a placeholder for discussion to be had. I did have the computed size in a `span_label`. However, that might cause both ui-tests here and lints elsewhere to become flaky wrt to their output (as the size is platform dependent).
```
error: the `Err`-variant returned via this `Result` is very large
--> $DIR/result_large_err.rs:36:34
|
LL | pub fn param_large_error<R>() -> Result<(), (u128, R, FullyDefinedLargeError)> {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The `Err` variant is unusually large, at least 128 bytes
```
bors [Tue, 30 Aug 2022 17:33:24 +0000 (17:33 +0000)]
Auto merge of #101203 - fortanix:raoul/remove_rls_from_git_submodule_update, r=jyn514
Avoid bootstrap from updating rls submodule
Our CI performing tests of the `x86_64-fortanix-unknown-sgx` failed with:
```
21:00:53 + ./configure --enable-lld --disable-rpath --set llvm.ninja=false --set rust.verbose-tests=true
21:00:53 + ./x.py test --stage=1 --target=x86_64-fortanix-unknown-sgx library/std --host= --no-doc --exclude src/tools/linkchecker
21:00:53 Building rustbuild
21:00:53 Finished dev [unoptimized] target(s) in 0.11s
21:00:53 Updating submodule src/tools/rls
21:00:54 Building stage0 std artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
21:00:54 Updating crates.io index
21:00:55 Updating git repository `[https://github.com/rust-lang/cargo`](https://github.com/rust-lang/cargo%60)
...
21:00:55 Updating git repository `[https://github.com/rust-lang/rust-clippy`](https://github.com/rust-lang/rust-clippy%60)
21:00:56 Updating git repository `[https://github.com/rust-lang/rustfmt`](https://github.com/rust-lang/rustfmt%60)
21:00:56 error: failed to select a version for `libgit2-sys`.
21:00:56 ... required by package `cargo v0.65.0 (https://github.com/rust-lang/cargo?rev=5514f1e0e1b3650ed8a78306198e90b66b292693#5514f1e0)`
21:00:56 ... which satisfies git dependency `cargo` of package `rls v1.41.0 (/home/jenkins/workspace/rust-sgx-ci/rust/src/tools/rls)`
21:00:56 versions that meet the requirements `^0.13.2` are: 0.13.4+1.4.2, 0.13.3+1.4.2, 0.13.2+1.4.2
21:00:56
21:00:56 the package `libgit2-sys` links to the native library `git2`, but it conflicts with a previous package which links to `git2` as well:
21:00:56 package `libgit2-sys v0.14.0+1.5.0`
21:00:56 ... which satisfies dependency `libgit2-sys = "^0.14.0"` of package `cargo v0.66.0 (/home/jenkins/workspace/rust-sgx-ci/rust/src/tools/cargo)`
21:00:56 Only one package in the dependency graph may specify the same links value. This helps ensure that only one copy of a native library is linked in the final binary. Try to adjust your dependencies so that only one package uses the links ='libgit2-sys' value. For more information, see https://doc.rust-lang.org/cargo/reference/resolver.html#links.
21:00:56
21:00:56 failed to select a version for `libgit2-sys` which could resolve this conflict
```
This is related to the version bump of `libgit2-sys` in #11004, but the root cause is the RLS is sunset (#100863). When the bootstrapper manages the git submodules, the wrong repo commit is checked out. This PR removes rls from the list of rust submodules.
bors [Tue, 30 Aug 2022 14:52:02 +0000 (14:52 +0000)]
Auto merge of #101195 - Dylan-DPC:rollup-rhjaz6r, r=Dylan-DPC
Rollup of 5 pull requests
Successful merges:
- #99517 (Display raw pointer as *{mut,const} T instead of *-ptr in errors)
- #99928 (Do not leak type variables from opaque type relation)
- #100473 (Attempt to normalize `FnDef` signature in `InferCtxt::cmp`)
- #100653 (Move the cast_float_to_int fallback code to GCC)
- #100941 (Point at the string inside literal and mention if we need string inte…)
Dylan DPC [Tue, 30 Aug 2022 11:26:09 +0000 (16:56 +0530)]
Rollup merge of #100653 - cuviper:fptoint_sat, r=michaelwoerister,antoyo
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.
Dylan DPC [Tue, 30 Aug 2022 11:26:08 +0000 (16:56 +0530)]
Rollup merge of #100473 - compiler-errors:normalize-the-fn-def-sig-plz, r=lcnr
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::<()>}`
```
Dylan DPC [Tue, 30 Aug 2022 11:26:07 +0000 (16:56 +0530)]
Rollup merge of #99928 - compiler-errors:issue-99914, r=oli-obk
Do not leak type variables from opaque type relation
The "root cause" is that we call `InferCtxt::resolve_vars_if_possible` (3d9dd681f520d1d59f38aed0056cf9474894cc74) 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.
bors [Tue, 30 Aug 2022 11:13:58 +0000 (11:13 +0000)]
Auto merge of #98100 - bjorn3:use_object_for_bitcode_reading, r=wesleywiser
Use object instead of LLVM for reading bitcode from rlibs
Together with changes I plan to make as part of https://github.com/rust-lang/rust/pull/97485 this will allow entirely removing usage of LLVM's archive reader and thus allow removing `archive_ro.rs` and `ArchiveWrapper.cpp`.
bors [Tue, 30 Aug 2022 08:29:42 +0000 (08:29 +0000)]
Auto merge of #101183 - Dylan-DPC:rollup-6kewixv, r=Dylan-DPC
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)
Dylan DPC [Tue, 30 Aug 2022 05:56:54 +0000 (11:26 +0530)]
Rollup merge of #101176 - notriddle:notriddle/rustdoc-table-display, r=jsha
rustdoc: remove unused CSS selectors for `.table-display`
This class was added to support the function signature [src] lockup. That lockup was changed in 34bd2b845b3acd84c5a9bddae3ff8081c19ec5e9 to use flexbox instead, leaving these selectors unused.
Dylan DPC [Tue, 30 Aug 2022 05:56:53 +0000 (11:26 +0530)]
Rollup merge of #101175 - tmandry:curse-push-hook, r=jyn514
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).
Dylan DPC [Tue, 30 Aug 2022 05:56:51 +0000 (11:26 +0530)]
Rollup merge of #101101 - RalfJung:read-pointer-as-bytes, r=oli-obk
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
```
projects / rust.git / log