`@Amanieu,` I didn't switch inline asms to use `DefKind::InlineAsm`, as I see little value doing that; given that no type inference is needed, it will only make typecking slower and more complex but will have no real gains. I did switch them to follow the same code path as inline asm during symbol resolution, though.
The `error: unconstrained generic constant` you mentioned in #76001 is due to the fact that `to_const` will actually add a wfness obligation to the constant, which we don't need for `asm_const`, so I have that removed.
bors [Wed, 18 May 2022 12:45:44 +0000 (12:45 +0000)]
Auto merge of #96867 - michaelwoerister:path-prefix-fixes-2, r=davidtwco
--remap-path-prefix: Fix duplicated path components in debuginfo
This PR fixes an issue with `--remap-path-prefix` where path components could appear twice in the remapped version of the path (e.g. https://github.com/rust-lang/rust/issues/78479). The underlying problem was that `--remap-path-prefix` is often used to map an absolute path to something that looks like a relative path, e.g.:
and relative paths in debuginfo are interpreted as being relative to the compilation directory. So if Cargo invokes the compiler with `/home/calvin/.cargo/registry/src/github.com-1ecc6299db9ec823/some_crate-0.1.0/src/lib.rs` as input and `/home/calvin/.cargo/registry/src/github.com-1ecc6299db9ec823/some_crate-0.1.0` as the compiler's working directory, then debuginfo will state that the working directory was `crates.io/some_crate-0.1.0` and the file is question was `crates.io/some_crate-0.1.0/src/lib.rs`, which combined gives the path:
With this PR the compiler will detect this situation and set up debuginfo in LLVM in a way that makes it strip the duplicated path components when emitting DWARF.
The PR also extracts the logic for making remapped paths absolute into a common helper function that is now used by debuginfo too (instead of just during crate metadata generation).
bors [Wed, 18 May 2022 09:53:01 +0000 (09:53 +0000)]
Auto merge of #97110 - Kobzol:pgo-pid-in-profile, r=lqd
Add PID to PGO profile data filename
After experimenting with PGO, it looks like the generated profile data files can be sometimes overwritten if there is a race condition, because multiple `rustc` processes are usually invoked in parallel by `cargo`. Adding the PID to the resulting profile filename pattern makes sure that the profiles will be stored in separate files.
This generates ~20 GiB more space on disk on the CI run, but that seems harmless (?). Merging the profiles is not a bottleneck, the perf. run took the same amount of time as usually (~1h 24m).
Dylan DPC [Wed, 18 May 2022 06:41:18 +0000 (08:41 +0200)]
Rollup merge of #97123 - ricked-twice:issue-96223-clean-fix, r=jackh726
Clean fix for #96223
Okay, so here we are (hopefully) :+1:
Closes #96223
Thanks a lot to `@jackh726` for your help and explanation :pray:
- Modified `InferCtxt::mk_trait_obligation_with_new_self_ty` to take as argument a `Binder<(TraitPredicate, Ty)>` instead of a `Binder<TraitPredicate>` and a separate `Ty` with no bound vars.
- Modified all call places to avoid calling `Binder::no_bounds_var` or `Binder::skip_binder` when it is not safe.
Dylan DPC [Wed, 18 May 2022 06:41:16 +0000 (08:41 +0200)]
Rollup merge of #96917 - marti4d:master, r=ChrisDenton
Make HashMap fall back to RtlGenRandom if BCryptGenRandom fails
With PR #84096, Rust `std::collections::hash_map::RandomState` changed from using `RtlGenRandom()` ([msdn](https://docs.microsoft.com/en-us/windows/win32/api/ntsecapi/nf-ntsecapi-rtlgenrandom)) to `BCryptGenRandom()` ([msdn](https://docs.microsoft.com/en-us/windows/win32/api/bcrypt/nf-bcrypt-bcryptgenrandom)) as its source of secure randomness after much discussion ([here](https://github.com/rust-random/getrandom/issues/65#issuecomment-753634074), among other places).
Unfortunately, after that PR landed, Mozilla Firefox started experiencing fairly-rare crashes during startup while attempting to initialize the `env_logger` crate. ([docs for env_logger](https://docs.rs/env_logger/latest/env_logger/)) The root issue is that on some machines, `BCryptGenRandom()` will fail with an `Access is denied. (os error 5)` error message. ([Bugzilla issue 1754490](https://bugzilla.mozilla.org/show_bug.cgi?id=1754490)) (Discussion in issue #94098)
Note that this is happening upon startup of Firefox's unsandboxed Main Process, so this behavior is different and separate from previous issues ([like this](https://bugzilla.mozilla.org/show_bug.cgi?id=1746254)) where BCrypt DLLs were blocked by process sandboxing. In the case of sandboxing, we knew we were doing something abnormal and expected that we'd have to resort to abnormal measures to make it work.
However, in this case we are in a regular unsandboxed process just trying to initialize `env_logger` and getting a panic. We suspect that this may be caused by a virus scanner or some other security software blocking the loading of the BCrypt DLLs, but we're not completely sure as we haven't been able to replicate locally.
It is also possible that Firefox is not the only software affected by this; we just may be one of the pieces of Rust software that has the telemetry and crash reporting necessary to catch it.
I have read some of the historical discussion around using `BCryptGenRandom()` in Rust code, and I respect the decision that was made and agree that it was a good course of action, so I'm not trying to open a discussion about a return to `RtlGenRandom()`. Instead, I'd like to suggest that perhaps we use `RtlGenRandom()` as a "fallback RNG" in the case that BCrypt doesn't work.
This pull request implements this fallback behavior. I believe this would improve the robustness of this essential data structure within the standard library, and I see only 2 potential drawbacks:
1. Slight added overhead: It should be quite minimal though. The first call to `sys::rand::hashmap_random_keys()` will incur a bit of initialization overhead, and every call after will incur roughly 2 non-atomic global reads and 2 easily predictable branches. Both should be negligible compared to the actual cost of generating secure random numbers
2. `RtlGenRandom()` is deprecated by Microsoft: Technically true, but as mentioned in [this comment on GoLang](https://github.com/golang/go/issues/33542#issuecomment-626124873), this API is ubiquitous in Windows software and actually removing it would break lots of things. Also, Firefox uses it already in [our C++ code](https://searchfox.org/mozilla-central/rev/5f88c1d6977e03e22d3420d0cdf8ad0113c2eb31/mfbt/RandomNum.cpp#25), and [Chromium uses it in their code as well](https://source.chromium.org/chromium/chromium/src/+/main:base/rand_util_win.cc) (which transitively means that Microsoft uses it in their own web browser, Edge). If there did come a time when Microsoft truly removes this API, it should be easy enough for Rust to simply remove the fallback in the code I've added here
Dylan DPC [Wed, 18 May 2022 06:41:15 +0000 (08:41 +0200)]
Rollup merge of #96378 - compiler-errors:trait-upcast-error, r=nagisa
Mention traits and types involved in unstable trait upcasting
Fixes #95972 by printing the traits being upcasted and the types being coerced that cause that upcasting...
---
the poor span mentioned in the original issue has nothing to do with trait upcasting diagnostic here...
> The original example I had that made me run into this issue had an even longer expression there (multiple chained
iterator methods) which just got all highlighted as one big block saying "somewhere here trait coercion is used and it's not allowed".
I don't think I can solve that issue in general without fixing the ObligationCauseCode and span that gets passed into Coerce.
Dylan DPC [Wed, 18 May 2022 06:41:13 +0000 (08:41 +0200)]
Rollup merge of #94639 - compiler-errors:rval-mutref, r=wesleywiser
Suggest dereferencing non-lval mutable reference on assignment
1. Adds deref suggestions for LHS of assignment (or assign-binop) when it implements `DerefMut`
2. Fixes missing deref suggestions for LHS when it isn't a place expr
Yuki Okushi [Tue, 17 May 2022 22:41:01 +0000 (07:41 +0900)]
Rollup merge of #97116 - RalfJung:ref-validity, r=oli-obk
interpret/validity: reject references to uninhabited types
According to https://doc.rust-lang.org/reference/behavior-considered-undefined.html, this is definitely UB. And we can check this without actually looking up anything in memory, we just need the reference value and its type, making this a great candidate for a validity invariant IMO and my favorite resolution of https://github.com/rust-lang/unsafe-code-guidelines/issues/77.
With this PR, Miri with `-Zmiri-check-number-validity` implements all my preferred options for what the validity invariants of our types could be. :)
CTFE has been doing recursive checking anyway, so this is backwards compatible but might change the error output. I will submit a PR with the new Miri tests soon.
Yuki Okushi [Tue, 17 May 2022 22:40:59 +0000 (07:40 +0900)]
Rollup merge of #97097 - chorman0773:add_tmm_clobers, r=joshtriplett
Add tmm_reg clobbers
This adds support for naming the 8 tile registers from intel AMX as clobbers from `asm!` invocations on x86_64 (only). It does not add the registers as input or output operands.
Yuki Okushi [Tue, 17 May 2022 22:40:55 +0000 (07:40 +0900)]
Rollup merge of #96647 - Enselic:fix-hrtb-for-wherepredicate, r=CraftSpider
rustdoc-json: Fix HRTBs for WherePredicate::BoundPredicate
Information about HRTBs are already present for `GenericBound:: TraitBound` and `FunctionPointer`. This PR adds HRTB info also to `WherePredicate::BoundPredicate`.
Use the same field name and type as for the other ones (`generic_params: Vec<GenericParamDef>`). I have verified that this gives rustdoc JSON clients the data they need and in a format that is easy to work with (see https://github.com/Enselic/public-api/pull/92).
I will be happy to add tests for this change (and bump `FORMAT_VERSION` which I just realized I forgot), but it is always nice to get one round of feedback first, so that I don't put a lot of effort into tests that then have to be discarded.
bors [Tue, 17 May 2022 19:50:44 +0000 (19:50 +0000)]
Auto merge of #92570 - jsha:rustdoc-search-refactor, r=GuillaumeGomez
Simplify rustdoc search test
Previously, rustdoc search attempted to parse search.js and extract out only certain methods and variables.
This change makes search.js and search-index.js loadable as [CommonJS modules](https://nodejs.org/api/modules.html#modules-commonjs-modules), so they can be loaded directly.
As part of that change, I had to separate execSearch from interacting with the DOM. This wound up being a nice cleanup that made more explicit what inputs it was taking.
I removed search.js' dependency on storage.js by moving hasOwnPropertyRustdoc directly into search.js, and replacing onEach with forEach in a path that is called by the tester.
ricked-twice [Tue, 17 May 2022 18:31:48 +0000 (20:31 +0200)]
Clean fix for #96223
- Modified `InferCtxt::mk_trait_obligation_with_new_self_ty` to take as
argument a `Binder<(TraitPredicate, Ty)>` instead of a
`Binder<TraitPredicate>` and a separate `Ty` with no bound vars.
- Modified all call places to avoid calling `Binder::no_bounds_var` or
`Binder::skip_binder` when it is not safe.
Previously, search.js relied on the DOM and the `window` object. It can now be
loaded in the absence of the DOM, for instance by Node. The same is true of
search-index.js.
This allows removing a lot of code from src/tools/rustdoc-js/tester.js that
tried to parse search.js and extract specific functions that were needed for
testing.
bors [Tue, 17 May 2022 15:04:50 +0000 (15:04 +0000)]
Auto merge of #96959 - nbdd0121:unwind, r=Amanieu
Prevent unwinding when `-C panic=abort` is used regardless declared ABI
Ensures that Rust code will abort with `-C panic=abort` regardless ABI used.
```rust
extern "C-unwind" {
fn may_unwind();
}
// Will be nounwind with `-C panic=abort`, despite `C-unwind` ABI.
pub unsafe extern "C-unwind" fn rust_item_that_can_unwind() {
may_unwind();
}
```
Current behaviour is that unwind will propagate through. While the current behaviour won't cause unsoundness it is inconsistent with the text reading of [RFC2945](https://rust-lang.github.io/rfcs/2945-c-unwind-abi.html).
I tweaked `fn_can_unwind` instead of tweaking `AbortUnwindingCalls` because this approach would allow Rust (non-direct) callers to also see that this function is nounwind, so it can prevent excessive landing pads generation.
For more discussions: https://rust-lang.zulipchat.com/#narrow/stream/210922-project-ffi-unwind/topic/soundness.20in.20mixed.20panic.20mode.
Yuki Okushi [Tue, 17 May 2022 10:01:32 +0000 (19:01 +0900)]
Rollup merge of #97079 - SparrowLii:successors, r=lcnr
Change `Successors` to `impl Iterator<Item = BasicBlock>`
This PR fixes the FIXME in `compiler\rustc_middle\src\mir\mod.rs`.
This can omit several `&`, `*` or `cloned` operations on Successros' generated elements
Yuki Okushi [Tue, 17 May 2022 10:01:30 +0000 (19:01 +0900)]
Rollup merge of #97009 - fortanix:raoul/unused_macro_sgx, r=thomcc
Allow `unused_macro_rules` in path tests
PR #96150 adds a new lint to warn about unused macro rules (arms/matchers). This causes errors in `library/std/src/path/tests.rs` on the `x86_64-fortanix-unknown-sgx` platform. This PR fixes compilation errors on that platform by allowing unused macro rules.
This parenthetical is problematic, because it suggests that the following is sound:
```rust
let layout = Layout::new::<[u8; 32]>();
let p1 = alloc(layout);
let p2 = realloc(p1, layout, 32);
if p1 == p2 {
p1.write([0; 32]);
dealloc(p1, layout);
} else {
dealloc(p2, layout);
}
```
At the very least, this isn't the case for [ANSI `realloc`](https://en.cppreference.com/w/c/memory/realloc)
> The original pointer `ptr` is invalidated and any access to it is undefined behavior (even if reallocation was in-place).
and [Windows `HeapReAlloc`](https://docs.microsoft.com/en-us/windows/win32/api/heapapi/nf-heapapi-heaprealloc) is unclear at best (`HEAP_REALLOC_IN_PLACE_ONLY`'s description may imply that the old pointer may be used if `HEAP_REALLOC_IN_PLACE_ONLY` is provided).
The conservative position is to just remove the parenthetical.
cc `@rust-lang/wg-unsafe-code-guidelines` `@rust-lang/wg-allocators`
bors [Sun, 15 May 2022 21:17:46 +0000 (21:17 +0000)]
Auto merge of #97057 - bjorn3:sync_cg_clif-2022-05-15, r=bjorn3
Sync rustc_codegen_cranelift
Since the last sync there have mostly been fixes of various sorts. I also changed cg_clif from using a custom driver to `-Zcodegen-backend` when built as separate project. When built as part of rust it was already using `-Zcodegen-backend`.
bors [Sun, 15 May 2022 18:52:28 +0000 (18:52 +0000)]
Auto merge of #97063 - Dylan-DPC:rollup-u5el7hb, r=Dylan-DPC
Rollup of 4 pull requests
Successful merges:
- #96947 (Add rustc_nonnull_optimization_guaranteed to Owned/Borrowed Fd/Socket)
- #97021 (Added note in documentation)
- #97042 (Add new eslint rule about brace style)
- #97060 (Fix use of SetHandleInformation on UWP)
Dylan DPC [Sun, 15 May 2022 16:41:27 +0000 (18:41 +0200)]
Rollup merge of #97060 - bdbai:fix/uwphandle, r=ChrisDenton
Fix use of SetHandleInformation on UWP
The use of `SetHandleInformation` (introduced in #96441 to make `HANDLE` inheritable) breaks UWP builds because it is not available for UWP targets.
Proposed workaround: duplicate the `HANDLE` with `inherit = true` and immediately close the old one. Traditional Windows Desktop programs are not affected.
Dylan DPC [Sun, 15 May 2022 16:41:25 +0000 (18:41 +0200)]
Rollup merge of #96947 - sunfishcode:sunfishcode/rustc-nonnull-optimization-guaranteed, r=joshtriplett
Add rustc_nonnull_optimization_guaranteed to Owned/Borrowed Fd/Socket
PR #94586 added support for using
`rustc_nonnull_optimization_guaranteed` on values where the "null" value
is the all-ones bitpattern.
Now that #94586 has made it to the stage0 compiler, add
`rustc_nonnull_optimization_guaranteed` to `OwnedFd`, `BorrowedFd`,
`OwnedSocket`, and `BorrowedSocket`, since these types all exclude
all-ones bitpatterns.
This allows `Option<OwnedFd>`, `Option<BorrowedFd>`, `Option<OwnedSocket>`,
and `Option<BorrowedSocket>` to be used in FFI declarations, as described
in the [I/O safety RFC].
bors [Sun, 15 May 2022 11:19:27 +0000 (11:19 +0000)]
Auto merge of #96885 - petrochenkov:linkstrict2, r=cjgillot,luqmana
rustc: Stricter checking for #[link] attributes
A subset of https://github.com/rust-lang/rust/pull/94962 that doesn't touch library renaming/reordering/deduplication.
`#[link]` attributes are checked for all kinds of unexpected arguments inside them.
I also tried to make wording for these errors more consistent, that's why some existing errors are changed, including errors for command line `-l` options.
Spans are also made more precise where possible.
Matthias Krüger [Sun, 15 May 2022 06:10:44 +0000 (08:10 +0200)]
Rollup merge of #97041 - eddyb:nixos-llvm-ci-patchelf, r=Mark-Simulacrum
Fix `download-ci-llvm` NixOS patching for `.so`s.
See https://github.com/rust-lang/rust/pull/95170#discussion_r872960686 - in short, `Path::ends_with` doesn't do the same thing as `str::ends_with`, and can only be used to check for whole file names, not extensions.
With this PR, I get the full suite of:
```
extracting /home/eddy/Projects/rust-A/build/cache/llvm-ebb80ec4e90f8622440f3e33562db0d6e6c66555-true/rust-dev-nightly-x86_64-unknown-linux-gnu.tar.xz to /home/eddy/Projects/rust-A/build/x86_64-unknown-linux-gnu/ci-llvm
info: you seem to be using Nix. Attempting to patch /home/eddy/Projects/rust-A/build/x86_64-unknown-linux-gnu/ci-llvm/bin/llvm-config
/nix/store/r4bzq2xilvv8fmqjg626hzwi22ah3hf4-rust-stage0-dependencies
info: you seem to be using Nix. Attempting to patch /home/eddy/Projects/rust-A/build/x86_64-unknown-linux-gnu/ci-llvm/bin/FileCheck
info: you seem to be using Nix. Attempting to patch /home/eddy/Projects/rust-A/build/x86_64-unknown-linux-gnu/ci-llvm/lib/libLLVM-14-rust-1.62.0-nightly.so
```
(that `libLLVM-14-rust-1.62.0-nightly.so` at the end having been missing before)
Matthias Krüger [Sun, 15 May 2022 06:10:42 +0000 (08:10 +0200)]
Rollup merge of #97032 - est31:unused_macro_rules, r=petrochenkov
Allow the unused_macro_rules lint for now
It was newly added by #96150 with warn by default, which is great as it gave exposure to the community, and their feedback gave me ideas for improvements.
Allowing the lint is good for two reasons:
* It makes the transition easier as e.g. allow directives won't fire the unknown lint warning once it is turned to warn by default in the future. The [commit that allowed the lint in fuchsia](https://fuchsia.googlesource.com/fuchsia/+/9d8f96517c3963de2f0e25598fd36061914524cd%5E%21/) had to allow unknown lints for example.
This is especially important compared to other lints in the unused group,
because the _ prefix trick doesn't exist for macro rules, allowing is the
only option (either of unused_macro_rules, or of the entire unused group,
but that is not as informative to readers). Allowing the lint also makes it
possible to work on possible heuristics for disabling the macro in specific
cases.
* It gives time for implementing heuristics for when to suppress the lint, e.g.
when `compile_error!` is invoked by that arm (so it's only there to yield an error).
Matthias Krüger [Sun, 15 May 2022 06:10:42 +0000 (08:10 +0200)]
Rollup merge of #96958 - GuillaumeGomez:settings-menu-display, r=jsha
Improve settings menu display and remove theme menu
We talked about improving the settings menu and we mentioned that firefox pocket was a nice inspiration so I implemented it. The result looks like this:
projects / rust.git / log