bors [Mon, 29 Nov 2021 01:35:33 +0000 (01:35 +0000)]
Auto merge of #91338 - matthiaskrgr:rollup-46ry8wi, r=matthiaskrgr
Rollup of 3 pull requests
Successful merges:
- #90131 (Fix a format_args span to be expansion)
- #90832 (Add 1.57.0 release notes)
- #90833 (Emit LLVM optimization remarks when enabled with `-Cremark`)
Matthias Krüger [Sun, 28 Nov 2021 22:45:17 +0000 (23:45 +0100)]
Rollup merge of #90833 - tmiasko:optimization-remarks, r=nikic
Emit LLVM optimization remarks when enabled with `-Cremark`
The default diagnostic handler considers all remarks to be disabled by
default unless configured otherwise through LLVM internal flags:
`-pass-remarks`, `-pass-remarks-missed`, and `-pass-remarks-analysis`.
This behaviour makes `-Cremark` ineffective on its own.
Fix this by configuring a custom diagnostic handler that enables
optimization remarks based on the value of `-Cremark` option. With
`-Cremark=all` enabling all remarks.
bors [Sun, 28 Nov 2021 22:29:57 +0000 (22:29 +0000)]
Auto merge of #90681 - workingjubilee:update-libc, r=JohnTitor
Update libc to 0.2.108
Changelog:
https://github.com/rust-lang/libc/releases/tag/0.2.107
https://github.com/rust-lang/libc/releases/tag/0.2.108
Primarily intended to pull in rust-lang/libc@fd331f65f214ea75b6210b415b5fd8650be15c73
This should help with https://github.com/rust-lang/rust/pull/90044
bors [Sun, 28 Nov 2021 17:14:04 +0000 (17:14 +0000)]
Auto merge of #91320 - matthiaskrgr:rollup-r209seq, r=matthiaskrgr
Rollup of 3 pull requests
Successful merges:
- #91251 (Perform Sync check on static items in wf-check instead of during const checks)
- #91308 (Fix ICE when lowering `trait A where for<'a> Self: 'a`)
- #91319 (Change output path to {{build-base}} for rustdoc scrape_examples ui test)
Matthias Krüger [Sun, 28 Nov 2021 16:11:10 +0000 (17:11 +0100)]
Rollup merge of #91251 - oli-obk:wf_sync_statics, r=matthewjasper
Perform Sync check on static items in wf-check instead of during const checks
r? `@RalfJung`
This check is solely happening on the signature of the static item and not on its body, therefor it belongs into wf-checking instead of const checking.
bors [Sun, 28 Nov 2021 13:04:27 +0000 (13:04 +0000)]
Auto merge of #91230 - eggyal:fallible-type-fold, r=jackh726
Make `TypeFolder::fold_*` return `Result`
Implements rust-lang/compiler-team#432.
Initially this is just a rebase of `@LeSeulArtichaut's` work in #85469 (abandoned; see https://github.com/rust-lang/rust/pull/85485#issuecomment-908781112). At that time, it caused a regression in performance that required some further exploration... with this rebased PR bors can hopefully report some perf analysis from which we can investigate further (if the regression is indeed still present).
bors [Sun, 28 Nov 2021 09:57:59 +0000 (09:57 +0000)]
Auto merge of #91311 - matthiaskrgr:rollup-ju9xizl, r=matthiaskrgr
Rollup of 3 pull requests
Successful merges:
- #90896 (Stabilize some `MaybeUninit` behavior as const)
- #91254 (Only check for errors in predicate when skipping impl assembly)
- #91303 (Miri: fix alignment check in array initialization)
Matthias Krüger [Sun, 28 Nov 2021 09:42:40 +0000 (10:42 +0100)]
Rollup merge of #91303 - RalfJung:array-init-align, r=oli-obk
Miri: fix alignment check in array initialization
https://github.com/rust-lang/rust/pull/85376 introduced a regression in Miri, reported at https://github.com/rust-lang/miri/issues/1919 and https://github.com/rust-lang/miri/issues/1925. This PR fixes that. I will add tests to Miri once this lands.
Matthias Krüger [Sun, 28 Nov 2021 09:42:39 +0000 (10:42 +0100)]
Rollup merge of #91254 - Aaron1011:impl-candidate-err-ty, r=lcnr
Only check for errors in predicate when skipping impl assembly
Prior to PR #91205, checking for errors in the overall obligation
would check checking the `ParamEnv`, due to an incorrect
`super_visit_with` impl. With this bug fixed, we will now
bail out of impl candidate assembly if the `ParamEnv` contains
any error types.
In practice, this appears to be overly conservative - when an error
occurs early in compilation, we end up giving up early for some
predicates that we could have successfully evaluated without overflow.
By only checking for errors in the predicate itself, we avoid causing
additional spurious 'type annotations needed' errors after a 'real'
error has already occurred.
With this PR, the diagnostic changes caused by PR #91205 are reverted.
Matthias Krüger [Sun, 28 Nov 2021 09:42:38 +0000 (10:42 +0100)]
Rollup merge of #90896 - jhpratt:stabilize_const_maybe_uninit, r=oli-obk
Stabilize some `MaybeUninit` behavior as const
This stabilizes the `MaybeUninit::as_ptr`, `MaybeUninit::assume_init`, and `MaybeUninit::assume_init_ref` as `const fn`. `MaybeUninit::as_mut_ptr` has been moved to a new flag: `const_maybe_uninit_as_mut_ptr`, which is blocked on #57349. `MaybeUninit::slice_assume_init_ref` can be `const fn` when the method is stabilized in general.
The relevant intrinsic has been stabilized as `const` as well, though this isn't user-visible. Due to the seemingly unrelated feature name I performed `rg const_assert_type` and found no other instances of it being used.
Jubilee Young [Mon, 8 Nov 2021 01:28:04 +0000 (17:28 -0800)]
Update libc to 0.2.108
Changelog:
https://github.com/rust-lang/libc/releases/tag/0.2.107
https://github.com/rust-lang/libc/releases/tag/0.2.108
Primarily intended to pull in fd331f65f214ea75b6210b415b5fd8650be15c73
This should help with https://github.com/rust-lang/rust/pull/90044
Thus the only way the **first** chunk could have an empty `broken` is if it is the **final** chunk, i.e. there is only one chunk total. And the only way that there could be one chunk total with an empty `broken` is if the whole input is valid utf8 and non-empty.
That condition has already been handled by an early return, so at the point that the first `REPLACEMENT` is being pushed, it's impossible for `first_broken` to be empty.
Aaron Hill [Fri, 26 Nov 2021 15:14:16 +0000 (09:14 -0600)]
Only check for errors in predicate when skipping impl assembly
Prior to PR #91205, checking for errors in the overall obligation
would check checking the `ParamEnv`, due to an incorrect
`super_visit_with` impl. With this bug fixed, we will now
bail out of impl candidate assembly if the `ParamEnv` contains
any error types.
In practice, this appears to be overly conservative - when an error
occurs early in compilation, we end up giving up early for some
predicates that we could have successfully evaluated without overflow.
By only checking for errors in the predicate itself, we avoid causing
additional spurious 'type annotations needed' errors after a 'real'
error has already occurred.
With this PR, the diagnostic changes caused by PR #91205 are reverted.
bors [Sat, 27 Nov 2021 11:31:26 +0000 (11:31 +0000)]
Auto merge of #89916 - the8472:advance_by-avoid-err-0, r=dtolnay
Fix Iterator::advance_by contract inconsistency
The `advance_by(n)` docs state that in the error case `Err(k)` that k is always less than n.
It also states that `advance_by(0)` may return `Err(0)` to indicate an exhausted iterator.
These statements are inconsistent.
Since only one implementation (Skip) actually made use of that I changed it to return Ok(()) in that case too.
While adding some tests I also found a bug in `Take::advance_back_by`.
Matthias Krüger [Sat, 27 Nov 2021 10:46:45 +0000 (11:46 +0100)]
Rollup merge of #91266 - jam1garner:fmt-ptr-fix, r=dtolnay
Use non-generic inner function for pointer formatting
Previously, despite the implementation being type-unaware, `fmt::Pointer`'s implementation for `*const T` in monomorphized. This affects:
* `fmt::Debug` for `*const T`
* `fmt::Debug` for `*mut T`
* `fmt::Pointer` for `*const T`
* `fmt::Pointer` for `*mut T`
And since the implementation is non-trivial, this results in a large amount of LLVM bitcode being generated. For example, with a large bindgen project with Debug implementations enabled, it will generate a lot of calls to `fmt::Debug for *const T`, which in turn will perform codegen for a copy of this function for every type.
For example, in a real-world bindgen'd header I've been testing with (4,189,245 lines of bindgen Rust with layout tests disabled) the difference between a slightly old nightly (`rustc 1.58.0-nightly (e249ce6b2 2021-10-30)`) and this PR:
<details>
<summary>Nightly (Click to Expand)</summary>
Output generated using `cargo llvm-lines` version 0.4.12.
Summary of differences:
| rustc Version | Total LLVM line count | `*const T as fmt::Pointer` LLVM lines | Compilation Time |
|-|-|-|-|
| `nightly` | 7256000 | 1815449 (25.0% of binary) | 537.014 |
| PR | 5684504 (-21.65%) | 266265 (4.7% of binary) (-85.3% from nightly) | 502.990 |
This results in a pretty noticeable as the majority of rustc's time is spent in either codegen or LLVM, in this case, and is significantly improved by disabling derives for `fmt::Debug`, as it prevents generating all this LLVM IR to be handled.
Here's a run time comparison with nightly on the same codebase (commit 454cc5fb built from source vs 37c8f25 from my PR built from source):
<details>
<summary>nightly (Click to Expand)</summary>
There were a few places in rustdoc where we would take static JS or CSS and rewrite it at doc generation time to insert values. This consolidates all the CSS instances into one CSS file and replaces the JS examples with data- attributes on the rustdoc-vars div.
Matthias Krüger [Sat, 27 Nov 2021 10:46:42 +0000 (11:46 +0100)]
Rollup merge of #91057 - the8472:clarify-parallelism-steady-state, r=dtolnay
Expand `available_parallelism` docs in anticipation of cgroup quota support
The "fixed" in "fixed steady state limits" means to exclude load-dependent resource prioritization
that would calculate to 100% of capacity on an idle system and less capacity on a loaded system.
Additionally I also exclude "system load" since it would be silly to try to identify
other, perhaps higher priority, processes hogging some CPU cores that aren't explicitly excluded
by masks/quotas/whatever.
Matthias Krüger [Sat, 27 Nov 2021 10:46:42 +0000 (11:46 +0100)]
Rollup merge of #90995 - the8472:hash-portability, r=dtolnay
Document non-guarantees for Hash
Dependence on endianness and type sizes was reported for enum discriminants in #74215 but it is a more general
issue since for example the default implementation of `Hasher::write_usize` uses native endianness.
Additionally the implementations of library types are occasionally changed as their internal fields
change or hashing gets optimized.
## Question
Should this go on the module level documentation instead since it also concerns `Hasher` to some extent and not just `Hash`?
Matthias Krüger [Sat, 27 Nov 2021 10:46:40 +0000 (11:46 +0100)]
Rollup merge of #83791 - the8472:relax-zip-side-effect-guarantee, r=dtolnay
Weaken guarantee around advancing underlying iterators in zip
The current guarantee (introduced in #52279) is too strong as it prevents adapters from exploiting knowledge about the iterator length and using counted loops for example because they would stop calling `next()` before it ever returned `None`. Additionally several nested zip iterators already fail to uphold this.
This does not yet remove any of the specialization code that tries (and sometimes fails) to uphold the guarantee for `next()`
because removing it would also affect `next_back()` in more surprising ways.
The intent is to be able to remove for example this branch
bors [Sat, 27 Nov 2021 07:58:00 +0000 (07:58 +0000)]
Auto merge of #90846 - cuviper:weak, r=dtolnay
Refactor weak symbols in std::sys::unix
This makes a few changes to the weak symbol macros in `sys::unix`:
- `dlsym!` is added to keep the functionality for runtime `dlsym`
lookups, like for `__pthread_get_minstack@GLIBC_PRIVATE` that we don't
want to show up in ELF symbol tables.
- `weak!` now uses `#[linkage = "extern_weak"]` symbols, so its runtime
behavior is just a simple null check. This is also used by `syscall!`.
- On non-ELF targets (macos/ios) where that linkage is not known to
behave, `weak!` is just an alias to `dlsym!` for the old behavior.
- `raw_syscall!` is added to always call `libc::syscall` on linux and
android, for cases like `clone3` that have no known libc wrapper.
The new `weak!` linkage does mean that you'll get versioned symbols if
you build with a newer glibc, like `WEAK DEFAULT UND statx@GLIBC_2.28`.
This might seem problematic, but old non-weak symbols can tie the build
to new versions too, like `dlsym@GLIBC_2.34` from their recent library
unification. If you build with an old glibc like `dist-x86_64-linux`
does, you'll still get unversioned `WEAK DEFAULT UND statx`, which may
be resolved based on the runtime glibc.
I also found a few functions that don't need to be weak anymore:
- Android can directly use `ftruncate64`, `pread64`, and `pwrite64`, as
these were added in API 12, and our baseline is API 14.
- Linux can directly use `splice`, added way back in glibc 2.5 and
similarly old musl. Android only added it in API 21 though.
Matthias Krüger [Fri, 26 Nov 2021 21:41:44 +0000 (22:41 +0100)]
Rollup merge of #91259 - jyn514:doctest-warnings, r=GuillaumeGomez
Remove `--display-doctest-warnings`
`--display-doctest-warnings` can be replicated in full with other existing features, there's no
need to have a separate option for it. This removes the option and documents the combination of other features to replicate it.
This also fixes a bug where `--test-args=--show-output` had no effect.
cc `@ollie27,` https://github.com/rust-lang/rust/pull/73314#issuecomment-668317262
Fixes https://github.com/rust-lang/rust/issues/41574
Matthias Krüger [Fri, 26 Nov 2021 21:41:41 +0000 (22:41 +0100)]
Rollup merge of #91240 - dtolnay:utf8width, r=Mark-Simulacrum
Saner formatting for UTF8_CHAR_WIDTH table
The way these lines were currently wrapped definitely does not look like someone's intentional formatting. It's likely they got disfigured by rustfmt at some point.
This commit rearranges it to a rustfmt-compatible formatting that I find easier to read.
If the first element of a top docblock is a heading, we still need to keep the indent, but only on this one (I added a test to check it). We need it because otherwise the anchor will go over the `[-]` toggle.
Matthias Krüger [Fri, 26 Nov 2021 21:41:39 +0000 (22:41 +0100)]
Rollup merge of #91197 - camelid:rename-resolvedpath, r=GuillaumeGomez,jyn514
rustdoc: Rename `Type::ResolvedPath` to `Type::Path` and don't re-export it
The new name is shorter, simpler, and consistent with `hir::Ty`. It can't be
re-exported since the name would conflict with the `clean::Path` struct. But
usually enum variants are referred to using their qualified names in Rust anyway
(and parts of rustdoc already do that with `clean::Type`), so this is also more
consistent with the language.
bors [Fri, 26 Nov 2021 21:35:53 +0000 (21:35 +0000)]
Auto merge of #91246 - nnethercote:faster-layout-array, r=dtolnay
Faster `Layout::array`
`Layout::array` is called (indirectly) by `Vec::push()`, which is typically instantiated many times, and so making it smaller can help with compile times because less LLVM IR is generated.
bors [Fri, 26 Nov 2021 16:30:42 +0000 (16:30 +0000)]
Auto merge of #91253 - matthiaskrgr:rollup-dnlcjmr, r=matthiaskrgr
Rollup of 4 pull requests
Successful merges:
- #91169 (Change cg_ssa's get_param to borrow the builder mutably)
- #91176 (If the thread does not get the lock in the short term, yield the CPU)
- #91212 (Fix ICE due to out-of-bounds statement index when reporting borrowck error)
- #91225 (Fix invalid scrollbar display on source code page)
Matthias Krüger [Fri, 26 Nov 2021 15:02:23 +0000 (16:02 +0100)]
Rollup merge of #91169 - RDambrosio016:master, r=bjorn3
Change cg_ssa's get_param to borrow the builder mutably
This is a small change to make `get_param` more flexible for codegens that may need to modify things when retrieving function parameters.
This will currently only be used by [rustc_codegen_nvvm](https://github.com/Rust-GPU/Rust-CUDA) (my own project), but may be useful to more codegens in the future.
This is needed because cg_nvvm needs to remap certain types to libnvvm-friendly types, such as `i128` -> `<2 x i64>`. Because cg_ssa does not give mutable access to the builder, i resorted to using a mutex:
```rs
fn get_param(&self, index: usize) -> Self::Value {
let val = llvm::get_param(self.llfn(), index as c_uint);
trace!("Get param `{:?}`", val);
unsafe {
let llfnty = LLVMRustGetFunctionType(self.llfn());
let map = self.remapped_integer_args.borrow();
if let Some((_, key)) = map.get(llfnty) {
if let Some((_, new_ty)) = key.iter().find(|t| t.0 == index) {
trace!("Casting irregular param {:?} to {:?}", val, new_ty);
return transmute_llval(
*self.llbuilder.lock().unwrap(),
&self.cx,
val,
*new_ty,
);
}
}
val
}
}
```
However, i predict this is pretty bad for performance, considering how much builders are called during codegen, so i would greatly appreciate having a more flexible API for this.
bors [Fri, 26 Nov 2021 13:42:35 +0000 (13:42 +0000)]
Auto merge of #91164 - Badel2:usefulness-stack-overflow, r=davidtwco
Fix stack overflow in `usefulness.rs`
Fix #88747
Applied the suggestion from `@nbdd0121,` not sure if this has any drawbacks. The first call to `ensure_sufficient_stack` is not needed to fix the test case, but I added it to be safe.
The current implementation is much more conservative than it needs to
be, because it's dealing with the size and alignment of a given `T`,
which are more restricted than an arbitrary `Layout`.
For example, imagine a struct with a `u32` and a `u4`. You can safely
create a `Layout { size_: 5, align_: 4 }` by hand, but
`Layout::new::<T>` will give `Layout { size_: 8, align_: 4}`, where the
size already has padding that accounts for the alignment. (And the
existing `debug_assert_eq!` in `Layout::array` already demonstrates that
no additional padding is required.)
bors [Fri, 26 Nov 2021 06:44:00 +0000 (06:44 +0000)]
Auto merge of #91181 - GuillaumeGomez:improve-rustdoc-gui-ci, r=jsha
Improve rustdoc-gui CI
As commented [here](https://github.com/rust-lang/rust/pull/91179#discussion_r756023009):
When the text isn't displayed, the color returned by puppeteer is always `rgba(0,0,0,0)`, which is definitely not the right value. To prevent this error from happening again, `browser-ui-test` will now fail if a CSS color check is run when the text isn't displayed.
Either this PR or #91179 is merged first, they'll conflict because I made changes to the same test file.
bors [Fri, 26 Nov 2021 03:57:55 +0000 (03:57 +0000)]
Auto merge of #85102 - estebank:point-at-assignment, r=oli-obk
Diagnostic tweaks
* On type mismatch caused by assignment, point at the source of the expectation
* Hide redundant errors
* Suggest `while let` when `let` is missing in some cases
David Tolnay [Fri, 26 Nov 2021 02:27:36 +0000 (18:27 -0800)]
Eliminate an unreachable codepath from String::from_utf8_lossy
Utf8Lossy's Iterator implementation ensures that only the final chunk
has an empty slice for broken. Thus the only way the first chunk could
have an empty broken is if it is the final chunk, i.e. there is only one
chunk total. And the only way that there could be one chunk total is if
the whole input is valid utf8 and non-empty. That condition has already
been handled by an early return, so at the point that the first
REPLACEMENT is being pushed, it's impossible for first_broken to be
empty.
Noah Lev [Wed, 24 Nov 2021 20:27:37 +0000 (12:27 -0800)]
Stop re-exporting `Type::ResolvedPath`
I would like to rename it to `Type::Path`, but then it can't be
re-exported since the name would conflict with the `Path` struct.
Usually enum variants are referred to using their qualified names in
Rust (and parts of rustdoc already do that with `clean::Type`), so this
is also more consistent with the language.
Esteban Küber [Fri, 7 May 2021 02:09:35 +0000 (19:09 -0700)]
On type mismatch caused by assignment, point at assignee
* Do not emit unnecessary E0308 after E0070
* Show fewer errors on `while let` missing `let`
* Hide redundant E0308 on `while let` missing `let`
* Point at binding definition when possible on invalid assignment
* do not point at closure twice
* do not suggest `if let` for literals in lhs
* account for parameter types
Matthias Krüger [Thu, 25 Nov 2021 14:05:40 +0000 (15:05 +0100)]
Rollup merge of #91185 - camelid:rm-force-overflow-checks, r=wesleywiser
Remove `-Z force-overflow-checks`
It was replaced several years ago by the stable option `-C overflow-checks`.
The goal was to delete the `-Z` flag once users had migrated [1].
Now that it's been several years, it makes sense to delete the old flag.
projects / rust.git / log