Rollup merge of #95735 - bjorn3:revert_inline_location_caller, r=compiler-errors
Revert "Mark Location::caller() as #[inline]"
This reverts https://github.com/rust-lang/rust/pull/95619. As noted in https://github.com/rust-lang/rust/pull/95619#issuecomment-1088548140 this seems to break several tests with cg_clif.
Rollup merge of #95626 - saethlin:pass-pointer-to-prctl, r=cuviper
Don't cast thread name to an integer for prctl
`libc::prctl` and the `prctl` definitions in glibc, musl, and the kernel headers are C variadic functions. Therefore, all the arguments (except for the first) are untyped. It is only the Linux man page which says that `prctl` takes 4 `unsigned long` arguments. I have no idea why it says this.
In any case, the upshot is that we don't need to cast the pointer to an integer and confuse Miri.
But in light of this... what are we doing with those three `0`s? We're passing 3 `i32`s to `prctl`, which doesn't fill me with confidence. The man page says `unsigned long` and all the constants in the linux kernel are macros for expressions of the form `1UL << N`. I'm mostly commenting on this because looks a whole lot like some UB that was found in SQLite a few years ago: <https://youtu.be/LbzbHWdLAI0?t=1925> that was related to accidentally passing a 32-bit value from a literal `0` instead of a pointer-sized value. This happens to work on x86 due to the size of pointers and happens to work on x86_64 due to the calling convention. But also, there is no good reason for an implementation to be looking at those arguments. Some other calls to `prctl` require that other arguments be zeroed, but not `PR_SET_NAME`... so why are we even passing them?
I would prefer to end such questions by either passing 3 `libc::c_ulong`, or not passing those at all, but I'm not sure which is better.
Auto merge of #95742 - Dylan-DPC:rollup-8n7o87y, r=Dylan-DPC
Rollup of 6 pull requests
Successful merges:
- #95342 (Ignore "format the world" commit in git blame)
- #95353 ([bootstrap] Give a hard error when filtering tests for a file that does not exist)
- #95649 (New mir-opt deref_separator)
- #95721 (Fix typo in bootstrap/setup.rs)
- #95730 (Rename RWLock to RwLock in std::sys.)
- #95731 (Check that all hidden types are the same and then deduplicate them.)
Rollup merge of #95731 - oli-obk:lazy_tait_regression, r=compiler-errors
Check that all hidden types are the same and then deduplicate them.
fixes #95538
This used to trigger a sanity check. Now we accept that there may be multiple places where a hidden type is constrained and we merge all of these at the end.
Ideally we'd merge eagerly, but that is a larger refactoring that I don't want to put into a backport
Rollup merge of #95730 - m-ou-se:rwlock-case, r=Dylan-DPC
Rename RWLock to RwLock in std::sys.
std::sync::RwLock is spelled with two capital letters, but std::sys's RWLock was spelled with three capital letters. This cleans that up and uses `RwLock` everywhere.
Rollup merge of #95353 - jyn514:invalid-filter-hard-error, r=Mark-Simulacrum
[bootstrap] Give a hard error when filtering tests for a file that does not exist
A common issue people run into when running compiletest is that filtering for files that don't exist is only a warning and not an error; running the whole test suite instead.
See for example https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/Question.20about.20compiletest.
This is especially bad when using `--bless`, which will modify all `.stderr` files.
Change bootstrap to require valid filters instead of discarding invalid filters and continuing.
Before:
```
Warning: Skipping "/home/jnelson/rust-lang/rust/src/test/rustdoc-ui/intra-doc/feature-gate-intra-doc-pointers.r": not a regular file or directory
Check compiletest suite=rustdoc-ui mode=ui (x86_64-unknown-linux-gnu(x86_64-unknown-linux-gnu) -> x86_64-unknown-linux-gnu(x86_64-unknown-linux-gnu))
running 163 tests
iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii.......................... 100/163
...............................................................
test result: ok. 89 passed; 0 failed; 74 ignored; 0 measured; 0 filtered out; finished in 7.20s
finished in 7.248 seconds
Build completed successfully in 0:00:08
```
After:
```
thread 'main' panicked at 'Invalid test suite filter "/home/jnelson/rust-lang/rust/src/test/rustdoc-ui/intra-doc/feature-gate-intra-doc-pointers.r": file or directory does not exist', src/bootstrap/util.rs:311:
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Build completed unsuccessfully in 0:00:08
```
Rollup merge of #95342 - jyn514:ignore-revs, r=Mark-Simulacrum
Ignore "format the world" commit in git blame
This tells github to hide it in its blame view: https://docs.github.com/en/repositories/working-with-files/using-files/viewing-a-file#ignore-commits-in-the-blame-view
It can also be used locally by running `git config blame.ignorerevsfile .git-blame-ignore-revs` (although it's advised to avoid `--global` since git gives a hard error when the file doesn't exist).
We may want to add more commits in later PRs, but this should be a good start.
Before: 
After: 
cc https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/Hide.20some.20commits.20in.20GitHub.20blame
Auto merge of #95723 - SparrowLii:const_goto, r=fee1-dead
enhance `ConstGoto` mir-opt by moving up `StorageDead` statements
From the `FIXME` in the implementation of `ConstGoto` miropt. We can move `StorageDead` statements up to the predecessor. This can expand the scope of application of this opt.
Auto merge of #95720 - ehuss:update-cargo, r=ehuss
Update cargo
5 commits in 1ef1e0a12723ce9548d7da2b63119de9002bead8..e2e2dddebe66dfc1403a312653557e332445308b
2022-03-31 00:17:18 +0000 to 2022-04-05 17:04:53 +0000
- Part 2 of RFC2906 -- allow inheriting from a different `Cargo.toml` (rust-lang/cargo#10517)
- File Cache is valid if checkout or contents hasn't changed (rust-lang/cargo#10507)
- Fix how scrape-examples handles proc macros (rust-lang/cargo#10533)
- tools: update checkout action on CI (rust-lang/cargo#10521)
- Don't error if no binaries were installed (rust-lang/cargo#10508)
Auto merge of #95711 - Dylan-DPC:rollup-ujss3oi, r=Dylan-DPC
Rollup of 4 pull requests
Successful merges:
- #95659 (Rely on #[link] attribute for unwind on Fuchsia.)
- #95684 (rustdoc: Fix item info display overflow)
- #95693 (interp: pass TyCtxt to Machine methods that do not take InterpCx)
- #95699 (fix: Vec leak when capacity is 0)
Rollup merge of #95699 - SparkyPotato:master, r=dtolnay
fix: Vec leak when capacity is 0
When `RawVec::with_capacity_in` is called with capacity 0, an allocation of size 0 is allocated.
However, `<RawVec as Drop>::drop` doesn't deallocate, since it only checks if capacity was 0. Fixed by not allocating when capacity is 0.
Rollup merge of #95693 - RalfJung:more-context, r=oli-obk
interp: pass TyCtxt to Machine methods that do not take InterpCx
This just seems like something you might need, so let's consistently have it.
One day we might have to add `ParamEnv` as well, though that seems less likely (and in Miri you can always use `reveal_all` anyway). It might make sense to have a type that packages `TyCtxt` and `ParamEnv`, this pairing occurs quite frequently in rustc...
The problem comes from the fact that `span` isn't `display: block` by default. Since `item-info` was already present on `<div>` in other places, I moved the last one to `div` as well.
Auto merge of #95469 - ChrisDenton:unsound-read-write, r=joshtriplett
Fix unsound `File` methods
This is a draft attempt to fix #81357. *EDIT*: this PR now tackles `read()`, `write()`, `read_at()`, `write_at()` and `read_buf`. Still needs more testing though.
cc `@jstarks,` can you confirm the the Windows team is ok with the Rust stdlib using `NtReadFile` and `NtWriteFile`?
~Also, I'm provisionally using `CancelIo` in a last ditch attempt to recover but I'm not sure that this is actually a good idea. Especially as getting into this state would be a programmer error so aborting the process is justified in any case.~ *EDIT*: removed, see comments.
Currently it's called in `parse_tt` every time a match rule is invoked.
This commit moves it so it's called instead once per match rule, in
`compile_declarative_macro. This is a performance win.
The commit also moves `compute_locs` out of `TtParser`, because there's
no longer any reason for it to be in there.
Auto merge of #95702 - Dylan-DPC:rollup-793rz6v, r=Dylan-DPC
Rollup of 8 pull requests
Successful merges:
- #88025 (ScmCredentials netbsd implementation.)
- #95473 (track individual proc-macro expansions in the self-profiler)
- #95547 (caution against ptr-to-int transmutes)
- #95585 (Explain why `&T` is cloned when `T` is not `Clone`)
- #95591 (Use revisions to track NLL test output (part 1))
- #95663 (diagnostics: give a special note for unsafe fn / Fn/FnOnce/FnMut)
- #95673 (:arrow_up: rust-analyzer)
- #95681 (resolve: Fix resolution of empty paths passed from rustdoc)
Rollup merge of #95591 - jackh726:nll-revisions-1, r=oli-obk
Use revisions to track NLL test output (part 1)
The idea here is 2 fold: 1) When we eventually do make NLL default on, that PR should be systematic in "delete revisions and corresponding error annotations" 2) This allows us to look at test NLL outputs in chunks. (Though, I've opted here not to "mark" these tests. There are some tests with NLL revisions *now* that will be missed. I expect we do a second pass once we have all the tests with NLL revisions; these tests should be easy enough to eyeball.)
The actual review here should be "easy", but a bit tedious. I expect we should manually go through each test output and confirm it's okay.
The majority of these are either: 1) Only span change (the one I see most common is highlighting an entire function call, rather than just the function name in that call) 2) "E0308 mismatched types" -> "lifetime does not live long enough" 3) "E0495 cannot infer an appropriate lifetime for lifetime parameter" -> "lifetime does not live long enough" 4) "E0312 lifetime of reference outlives lifetime of borrowed content" -> "lifetime does not live long enough" 5) "E0759 `XXX` has an anonymous lifetime `'_` but it needs to satisfy a `'static` lifetime requirement" -> "lifetime does not live long enough" 6) "E0623 lifetime mismatch" -> "lifetime does not live long enough"
Other than the now lack of an error code, most of these look fine (with most giving more helpful suggestions now).
`rfc1623` output isn't great.
cc ``@marmeladema`` if you want to look through these
Let's r? ``@oli-obk`` since you've commented on the Zulip thread ;)
Rollup merge of #95547 - RalfJung:ptr-int-transmutes, r=scottmcm
caution against ptr-to-int transmutes
I don't know how strong of a statement we want to make here, but I am very concerned that the current docs could be interpreted as saying that ptr-to-int transmutes are just as okay as transmuting `*mut T` into an `&mut T`.
Examples [like this](https://github.com/rust-lang/unsafe-code-guidelines/issues/286#issuecomment-1085144431) show that ptr-to-int transmutes are deeply suspicious -- they are either UB, or they don't round-trip properly, or we have to basically say that `transmute` will actively look for pointers and do all the things a ptr-to-int cast does (which includes a global side-effect of marking the pointed-to allocation as 'exposed').
Another alternative might be to simply not talk about them... but we *do* want people to use casts rather than transmutes for this.
Rollup merge of #95473 - lqd:macro-expansion, r=petrochenkov
track individual proc-macro expansions in the self-profiler
As described in [this zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Macro.20expansion.20performance.20on.20complex.20macros/near/275063190), users don't currently have a lot of information to diagnose macro expansion performance issues. That comment suggests using the macro names to add further timing information.
This PR starts to do this for proc-macros which have the same issue, and performance problems happening in the wild in [this other zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/247081-t-compiler.2Fperformance/topic/Identifying.20proc-macro.20slowdowns) could be helped by such information.
It uses the available proc-macro name to track their individual expansions with self-profiling events.
r? `@Aaron1011` who mentioned this idea originally
Auto merge of #94527 - oli-obk:undef_scalars, r=nagisa,erikdesjardin
Let CTFE to handle partially uninitialized unions without marking the entire value as uninitialized.
follow up to #94411
To fix https://github.com/rust-lang/rust/issues/69488 and by extension fix https://github.com/rust-lang/rust/issues/94371, we should stop treating types like `MaybeUninit<usize>` as something that the `Scalar` type in the interpreter engine can represent. So we add a new field to `abi::Primitive` that records whether the primitive is nested in a union
Auto merge of #95680 - Dylan-DPC:rollup-7jldtnz, r=Dylan-DPC
Rollup of 4 pull requests
Successful merges:
- #95525 (Suggest derivable trait on E0277 error)
- #95654 (diagnostics: use correct span for const generics)
- #95660 (Update panic docs to make it clearer when to use panic vs Result)
- #95670 (Refactor: remove unused function parameters)
Rollup merge of #95660 - yaahc:panic-docs-update, r=Dylan-DPC
Update panic docs to make it clearer when to use panic vs Result
This is based on a question that came up in one of my [error handling office hours](https://twitter.com/yaahc_/status/1506376624509374467?s=20&t=Sp-cEjrx5kpMdNsAGPOo9w) meetings. I had a user who was fairly familiar with error type design, thiserror and anyhow, and rust in general, but who was still confused about when to use panics vs when to use Result and `Error`.
This will also be cross referenced in an error handling FAQ that I will be creating in the https://github.com/rust-lang/project-error-handling repo shortly.
Rémy Rakic [Wed, 30 Mar 2022 13:14:25 +0000 (15:14 +0200)]
track proc-macro expansions in the self-profiler
Use the proc-macro descr to track their individual expansions with
self-profiling events. This will help diagnose performance issues
with slow proc-macros.
Auto merge of #95667 - Dylan-DPC:rollup-n7xzs3y, r=Dylan-DPC
Rollup of 5 pull requests
Successful merges:
- #95234 (bootstrap.py: nixos check in /etc/os-release with quotes)
- #95449 (Fix `x doc --stage 0 compiler`)
- #95512 (diagnostics: translation infrastructure)
- #95607 (Note invariance reason for FnDef types)
- #95645 (Fix intra doc link ICE when trying to get traits in scope for primitive)
Rollup merge of #95607 - compiler-errors:issue-95272, r=Aaron1011
Note invariance reason for FnDef types
Fixes #95272. Is it worthwhile even printing a variance explanation here? Or should I try to track down which function parameter is responsible for the invariance?
Rollup merge of #95512 - davidtwco:diagnostic-translation, r=oli-obk
diagnostics: translation infrastructure
An implementation of the infrastructure required to have translatable diagnostic messages.
- Introduces a `DiagnosticMessage` type which can represent both the current non-translatable messages and identifiers for [Fluent](https://projectfluent.org/).
- Modifies current diagnostic API so that existing calls still work but `DiagnosticMessage`s can be provided too.
- Adds support for always loading a "fallback bundle" containing the English diagnostic messages, which are used when a `DiagnosticMessage::FluentIdentifier` is used in a diagnostic being emitted.
- Adds support for loading a "primary bundle" which contains the user's preferred language translation, and is used preferentially when it contains a diagnostic message being emitted. Primary bundles are loaded either from the path provided to `-Ztranslate-alternate-ftl` (for testing), or from the sysroot at `$sysroot/locale/$locale/*.ftl` given a locale with `-Ztranslate-lang` (which is parsed as a language identifier).
- Adds "diagnostic args" which enable normally-interpolated variables to be made available as variables for Fluent messages to use.
- Updates `#[derive(SessionDiagnostic)]` so that it can only be used for translatable diagnostics and update the handful of diagnostics which used the derive to be translatable.
For example, the following diagnostic...
```rust
#[derive(SessionDiagnostic)]
#[error = "E0195"]
pub struct LifetimesOrBoundsMismatchOnTrait {
#[message = "lifetime parameters or bounds on {item_kind} `{ident}` do not match the trait declaration"]
#[label = "lifetimes do not match {item_kind} in trait"]
pub span: Span,
#[label = "lifetimes in impl do not match this {item_kind} in trait"]
pub generics_span: Option<Span>,
pub item_kind: &'static str,
pub ident: Ident,
}
```
```fluent
typeck-lifetimes-or-bounds-mismatch-on-trait =
lifetime parameters or bounds on {$item_kind} `{$ident}` do not match the trait declaration
.label = lifetimes do not match {$item_kind} in trait
.generics-label = lifetimes in impl do not match this {$item_kind} in trait
```
Rollup merge of #95449 - jyn514:doc-stage-0, r=ehuss
Fix `x doc --stage 0 compiler`
Eric figured out the fix to this almost 2 years ago, I just didn't read his comment carefully enough at the timme.
The issue was that fake rustc and fake rustdoc were inconsistent about when they passed `--sysroot` to the real compiler.
Change them to consistently only pass it when `--target` is present.
cc https://github.com/rust-lang/rust/issues/74976#issuecomment-667265945
Fixes https://github.com/rust-lang/rust/issues/79980
Rollup merge of #95234 - ben0x539:nixquotes, r=Dylan-DPC
bootstrap.py: nixos check in /etc/os-release with quotes
Per https://www.freedesktop.org/software/systemd/man/os-release.html,
> Variable assignment values must be enclosed in double or single quotes
> if they include spaces, semicolons or other special characters outside
> of A–Z, a–z, 0–9. (Assignments that do not include these special
> characters may be enclosed in quotes too, but this is optional.)
So, past `ID=nixos`, let's also check for `ID='nixos'` and `ID="nixos"`.
One of these is necessary between nixos/nixpkgs#162168 and
nixos/nixpkgs#164068, but this seems more correct either way.
In #95555 this was moved out of `parse_tt_inner` and `nameize` into
`compute_locs`. But the next commit will be moving `compute_locs`
outwards to a place that isn't suitable for the missing fragment
identifier checking. So this reinstates the old checking.
David Wood [Sun, 3 Apr 2022 03:53:01 +0000 (04:53 +0100)]
session: opt for enabling directionality markers
Add an option for enabling and disabling Fluent's directionality
isolation markers in output. Disabled by default as these can render in
some terminals and applications.
David Wood [Sat, 2 Apr 2022 05:18:48 +0000 (06:18 +0100)]
typeck: remove now-unnecessary parameter from diag
Removes `expected_pluralize` parameter from diagnostic struct which is
no longer necessary as the Fluent message can determine the correct
pluralization.
David Wood [Sat, 2 Apr 2022 05:09:43 +0000 (06:09 +0100)]
errors: don't try load default locale from sysroot
If the user requests a diagnostic locale of "en-US" then it doesn't make
sense to try and load that from the `$sysroot` because it is just the
default built-in locale.
David Wood [Thu, 31 Mar 2022 08:21:42 +0000 (09:21 +0100)]
macros: optional error codes
In an effort to make it easier to port diagnostics to
`SessionDiagnostic` (for translation) and since translation slugs could
replace error codes, make error codes optional in the
`SessionDiagnostic` derive.
projects / rust.git / log