| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
TB diagnostics: avoid printing irrelevant events
History contains some events that are relevant to the location but not useful to understand the error.
We can make the selection of events more precise, from only "does it affect the location" to also "is it relevant for this kind of error"
This is also the occasion to fix https://github.com/rust-lang/miri/pull/2867#issuecomment-1530065511
[Solved] Draft: find a way for blanks in the history to not be confusing, as with the current version the history can show the creation as `Reserved` then show where it transitioned from `Frozen` to `Disabled`, but it will say nothing of the `Reserved -> Frozen` leading up to it.
|
|
Rollup of 7 pull requests
Successful merges:
- #112031 (Migrate `item_proc_macro` to Askama)
- #112053 (Remove `-Zcgu-partitioning-strategy`.)
- #112069 (offset_of: don't require type to be `Sized`)
- #112084 (enhancements on build_helper utilization and rustdoc-gui-test)
- #112096 (Remove array_zip)
- #112108 (Fix re-export of doc hidden item inside private item not displayed)
- #112113 (rustdoc: simplify `clean` by removing `FnRetTy`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
enhancements on build_helper utilization and rustdoc-gui-test
This change provides codebase improvements, resolves `FIXME` in `rustdoc-gui-test` and makes `rustdoc-gui` test able to find local `node_modules` directory outside of the source root.
|
|
|
|
refactor and cleanup the leak check, add it to new solver
ended up being a bit more involved than I wanted but is hopefully still easy enough to review as a single PR, can split it into separate ones otherwise.
this can be reviewed commit by commit:
a473d55cdb9284aa2b01282d1b529a2a4d26547b 31a686646534ca006d906ec757ece4e771d6f973 949039c107852a5e36361c08b62821a0613656f5 242917bf5170d9a723c6c8e23e9d9d0c2fa8dc9d ed2b25a7aa28be3184be9e3022c2796a30eaad87 are all pretty straightforward.
03dd83b4c3f4ff27558f5c8ab859bd9f83db1d04 makes it easier to refactor coherence in a later commit, see the commit description, cc `@oli-obk`
4fe311d807a77b6270f384e41689bf5d58f46aec I don't quite remember what we wanted to test here, this definitely doesn't test that the occurs check doesn't cause incorrect errors in coherence, also cc `@oli-obk` here. I may end up writing a new test for this myself later.
5c200d88a91b75bd0875b973150655bd581ef97a is the main refactor of the leak check, changing it to take the `outer_universe` instead of getting it from a snapshot. Using a snapshot requires us to be in a probe which we aren't in the new solver, it also just feels dirty as snapshots don't really have anything to do with universes.
with all of this cfc230d54188d9c7ed867a9a0d1f51be77b485f9 is now kind of trivial.
r? `@nikomatsakis`
|
|
|
|
`EarlyBinder::new` -> `EarlyBinder::bind`
for consistency with `Binder::bind`. it may make sense to also add `EarlyBinder::dummy` in places where we know that no parameters exist, but I left that out of this PR.
r? `@jackh726` `@kylematsuda`
|
|
Uplift `clippy::invalid_utf8_in_unchecked` lint
This PR aims at uplifting the `clippy::invalid_utf8_in_unchecked` lint into two lints.
## `invalid_from_utf8_unchecked`
(deny-by-default)
The `invalid_from_utf8_unchecked` lint checks for calls to `std::str::from_utf8_unchecked` and `std::str::from_utf8_unchecked_mut` with an invalid UTF-8 literal.
### Example
```rust
unsafe {
std::str::from_utf8_unchecked(b"cl\x82ippy");
}
```
### Explanation
Creating such a `str` would result in undefined behavior as per documentation for `std::str::from_utf8_unchecked` and `std::str::from_utf8_unchecked_mut`.
## `invalid_from_utf8`
(warn-by-default)
The `invalid_from_utf8` lint checks for calls to `std::str::from_utf8` and `std::str::from_utf8_mut` with an invalid UTF-8 literal.
### Example
```rust
std::str::from_utf8(b"ru\x82st");
```
### Explanation
Trying to create such a `str` would always return an error as per documentation for `std::str::from_utf8` and `std::str::from_utf8_mut`.
-----
Mostly followed the instructions for uplifting a clippy lint described here: https://github.com/rust-lang/rust/pull/99696#pullrequestreview-1134072751
````@rustbot```` label: +I-lang-nominated
r? compiler
-----
For Clippy:
changelog: Moves: Uplifted `clippy::invalid_utf8_in_unchecked` into rustc
|
|
Signed-off-by: ozkanonur <work@onurozkan.dev>
|
|
Signed-off-by: ozkanonur <work@onurozkan.dev>
|
|
Make `TrustedStep` require `Copy`
All the implementations of the trait already are `Copy`, and this seems to be enough to simplify the implementations enough to make the MIR inliner willing to inline basics like `Range::next`.
r? `@thomcc`
|
|
deps: bump crates
Updates few deps:
drops a lot of cxx* crates:
```console
$ cargo update -p iana-time-zone-haiku
Updating crates.io index
Updating cc v1.0.77 -> v1.0.79
Removing codespan-reporting v0.11.1
Removing cxx v1.0.94
Removing cxx-build v1.0.94
Removing cxxbridge-flags v1.0.94
Removing cxxbridge-macro v1.0.94
Updating iana-time-zone-haiku v0.1.1 -> v0.1.2
Removing link-cplusplus v1.0.8
Removing scratch v1.0.5
```
cc: https://github.com/rust-lang/cc-rs/releases/tag/1.0.78, https://github.com/rust-lang/cc-rs/releases/tag/1.0.79
iana-time-zone-haiku: https://github.com/strawlab/iana-time-zone/releases/tag/haiku%2Fv0.1.2
fixed https://github.com/crossbeam-rs/crossbeam/pull/972 (similar fixed in rust repo https://github.com/rust-lang/rust/pull/110089)
```console
$ cargo update -p crossbeam-channel
Updating crates.io index
Updating crossbeam-channel v0.5.6 -> v0.5.8
```
https://github.com/crossbeam-rs/crossbeam/blob/master/crossbeam-channel/CHANGELOG.md#version-058
dedupes memoffset versions:
```console
$ cargo update -p crossbeam-epoch
Updating crates.io index
Updating crossbeam-epoch v0.9.13 -> v0.9.14
Removing memoffset v0.7.1
```
https://github.com/crossbeam-rs/crossbeam/blob/master/crossbeam-epoch/CHANGELOG.md#version-0914
https://github.com/Gilnaa/memoffset/compare/v0.6.5...v0.8.0
https://github.com/rust-lang/rust/pull/108638#discussion_r1193157265
dedupes bstr versions
```console
$ cargo update -p ignore -p opener
Updating crates.io index
Removing bstr v0.2.17
Updating globset v0.4.9 -> v0.4.10
Updating ignore v0.4.18 -> v0.4.20
Updating opener v0.5.0 -> v0.5.2
```
globset https://github.com/BurntSushi/ripgrep/commit/ac8fecbbf2e3be6dc3fca2ebc1a31a046d57553a
ignore https://github.com/BurntSushi/ripgrep/commits/master/crates/ignore hard to track, but drop dep on crossbeam-utils (https://github.com/BurntSushi/ripgrep/commit/e95254a86f484eec663be4714924d91d3cf39cb8), don't stat git if require_git is false (https://github.com/BurntSushi/ripgrep/commit/009dda1488ac6a01725b3e49ec9b81a1edf8036d) and added bunch of formats to ignore list
opener https://github.com/Seeker14491/opener/compare/v0.5.0...v0.5.2 nothing interesting
|
|
|
|
|
|
|
|
Signed-off-by: ozkanonur <work@onurozkan.dev>
|
|
Move tests
r? `@petrochenkov`
|
|
|
|
Load only the crate header for `locator::crate_matches`
Previously, we used the following info to determine whether to load the crate:
1. The METADATA_HEADER, which includes a METADATA_VERSION constant
2. The embedded rustc version
3. Various metadata in the `CrateRoot`, including the SVH
This worked ok most of the time. Unfortunately, when building locally the rustc version is always
the same because `omit-git-hash` is on by default. That meant that we depended only on 1 and 3, and
we are not very good about bumping METADATA_VERSION (it's currently at 7) so in practice we were
only depending on 3. `CrateRoot` is a very large struct and changes somewhat regularly, so this led
to a steady stream of crashes from trying to load it.
Change the logic to add an intermediate step between 2 and 3: introduce a new `CrateHeader` struct
that contains only the minimum info needed to decide whether the crate should be loaded or not. That
avoids having to load all of `CrateRoot`, which in practice means we should crash much less often.
Note that this works because the SVH should be different between any two dependencies, even if the
compiler has changed, because we use `-Zbinary-dep-depinfo` in bootstrap. See
https://github.com/rust-lang/rust/pull/111329#issuecomment-1538303474 for more details about how the
original crash happened.
|
|
Use `Cow` in `{D,Subd}iagnosticMessage`.
Each of `{D,Subd}iagnosticMessage::{Str,Eager}` has a comment:
```
// FIXME(davidtwco): can a `Cow<'static, str>` be used here?
```
This commit answers that question in the affirmative. It's not the most compelling change ever, but it might be worth merging.
This requires changing the `impl<'a> From<&'a str>` impls to `impl From<&'static str>`, which involves a bunch of knock-on changes that require/result in call sites being a little more precise about exactly what kind of string they use to create errors, and not just `&str`. This will result in fewer unnecessary allocations, though this will not have any notable perf effects given that these are error paths.
Note that I was lazy within Clippy, using `to_string` in a few places to preserve the existing string imprecision. I could have used `impl Into<{D,Subd}iagnosticMessage>` in various places as is done in the compiler, but that would have required changes to *many* call sites (mostly changing `&format("...")` to `format!("...")`) which didn't seem worthwhile.
r? `@WaffleLapkin`
|
|
|
|
|
|
Each of `{D,Subd}iagnosticMessage::{Str,Eager}` has a comment:
```
// FIXME(davidtwco): can a `Cow<'static, str>` be used here?
```
This commit answers that question in the affirmative. It's not the most
compelling change ever, but it might be worth merging.
This requires changing the `impl<'a> From<&'a str>` impls to `impl
From<&'static str>`, which involves a bunch of knock-on changes that
require/result in call sites being a little more precise about exactly
what kind of string they use to create errors, and not just `&str`. This
will result in fewer unnecessary allocations, though this will not have
any notable perf effects given that these are error paths.
Note that I was lazy within Clippy, using `to_string` in a few places to
preserve the existing string imprecision. I could have used `impl
Into<{D,Subd}iagnosticMessage>` in various places as is done in the
compiler, but that would have required changes to *many* call sites
(mostly changing `&format("...")` to `format!("...")`) which didn't seem
worthwhile.
|
|
MIR: opt-in normalization of `BasicBlock` and `Local` numbering
This doesn't matter at all for actual codegen, but after spending some time reading pre-codegen MIR, I was wishing I didn't have to jump around so much in reading post-inlining code.
So this add two passes that are off by default for every mir level, but can be enabled (`-Zmir-enable-passes=+ReorderBasicBlocks,+ReorderLocals`) for humans.
|
|
|
|
|
|
Add support for LLVM SafeStack
Adds support for LLVM [SafeStack] which provides backward edge control
flow protection by separating the stack into two parts: data which is
only accessed in provable safe ways is allocated on the normal stack
(the "safe stack") and all other data is placed in a separate allocation
(the "unsafe stack").
SafeStack support is enabled by passing `-Zsanitizer=safestack`.
[SafeStack]: https://clang.llvm.org/docs/SafeStack.html
cc `@rcvalle` #39699
|
|
impl of is_relevant on transitions makes for much less noise in error messages
Co-authored-by: Ralf Jung <post@ralfj.de>
|
|
|
|
r=albertlarsan68,oli-obk
new tool `rustdoc-gui-test`
Implements new tool `rustdoc-gui-test` that allows using compiletest headers for `rustdoc-gui` tests.
|
|
|
|
Adds support for LLVM [SafeStack] which provides backward edge control
flow protection by separating the stack into two parts: data which is
only accessed in provable safe ways is allocated on the normal stack
(the "safe stack") and all other data is placed in a separate allocation
(the "unsafe stack").
SafeStack support is enabled by passing `-Zsanitizer=safestack`.
[SafeStack]: https://clang.llvm.org/docs/SafeStack.html
|
|
Previously, we would normalize *all* of
- the absolute path to the repository checkout
- the /rustc/$sha for stage1 (if `remap-debuginfo` was enabled)
- the /rustc/$sha for download-rustc
- the sysroot for download-rustc
Now, we consistently only normalize /rustc/FAKE_PREFIX. Not only is this
much simpler, but it also avoids ongoing maintenance for download-rustc
and makes it much less likely that tests break by accident.
- Change `tests/ui/track-diagnostics/track6.rs` to use a relative path
instead of an absolute one. I am not actually sure why `track_caller`
works here, but it does seem to work :shrug:
- Pass `-Zsimulate-remapped-rust-src-base=/rustc/FAKE_PREFIX` to all
suites, not just UI. In particular, mir-opt tests emit /rustc/ paths
in their output.
|
|
This makes go-to-definition, etc. work in cg_clif, cg_gcc, rust-analyzer, and src/tools/x.
|
|
|
|
|
|
|
|
|
|
update iana-time-zone-haiku to drop bumch of cxx* deps
cargo update -p iana-time-zone-haiku
Updating crates.io index
Updating cc v1.0.77 -> v1.0.79
Removing codespan-reporting v0.11.1
Removing cxx v1.0.94
Removing cxx-build v1.0.94
Removing cxxbridge-flags v1.0.94
Removing cxxbridge-macro v1.0.94
Updating iana-time-zone-haiku v0.1.1 -> v0.1.2
Removing link-cplusplus v1.0.8
Removing scratch v1.0.5
fixes known issue https://github.com/crossbeam-rs/crossbeam/pull/972
cargo update -p crossbeam-channel
Updating crates.io index
Updating crossbeam-channel v0.5.6 -> v0.5.8
dedupes memoffset versions
cargo update -p crossbeam-epoch
Updating crates.io index
Updating crossbeam-epoch v0.9.13 -> v0.9.14
Removing memoffset v0.7.1
dedupes bstr versions
cargo update -p ignore -p opener
Updating crates.io index
Removing bstr v0.2.17
Updating globset v0.4.9 -> v0.4.10
Updating ignore v0.4.18 -> v0.4.20
Updating opener v0.5.0 -> v0.5.2
|
|
Ensure Fluent messages are in alphabetical order
Fixes #111847
This adds a tidy check to ensure Fluent messages are in alphabetical order, as well as sorting all existing messages. I think the error could be worded better, would appreciate suggestions.
<details>
<summary>Script used to sort files</summary>
```py
import sys
import re
fn = sys.argv[1]
with open(fn, 'r') as f:
data = f.read().split("\n")
chunks = []
cur = ""
for line in data:
if re.match(r"^([a-zA-Z0-9_]+)\s*=\s*", line):
chunks.append(cur)
cur = ""
cur += line + "\n"
chunks.append(cur)
chunks.sort()
with open(fn, 'w') as f:
f.write(''.join(chunks).strip("\n\n") + "\n")
```
</details>
|
|
|
|
Remove ExpnKind::Inlined.
Suggested in https://github.com/rust-lang/rust/pull/111815#issuecomment-1561903339
r? ``@oli-obk``
|
|
Support #[global_allocator] without the allocator shim
This makes it possible to use liballoc/libstd in combination with `--emit obj` if you use `#[global_allocator]`. This is what rust-for-linux uses right now and systemd may use in the future. Currently they have to depend on the exact implementation of the allocator shim to create one themself as `--emit obj` doesn't create an allocator shim.
Note that currently the allocator shim also defines the oom error handler, which is normally required too. Once `#![feature(default_alloc_error_handler)]` becomes the only option, this can be avoided. In addition when using only fallible allocator methods and either `--cfg no_global_oom_handling` for liballoc (like rust-for-linux) or `--gc-sections` no references to the oom error handler will exist.
To avoid this feature being insta-stable, you will have to define `__rust_no_alloc_shim_is_unstable` to avoid linker errors.
(Labeling this with both T-compiler and T-lang as it originally involved both an implementation detail and had an insta-stable user facing change. As noted above, the `__rust_no_alloc_shim_is_unstable` symbol requirement should prevent unintended dependence on this unstable feature.)
|
|
|
|
|
|
|
|
|
