`UsePath` contains a `SmallVec<[Res; 3]>`. This holds up to three `Res`
results, one per namespace (type, value, or macro). `lower_import_res`
takes a `PerNS<Option<Res<NodeId>>>` result and lowers it into the
`SmallVec`. This is pretty weird. The input `PerNS` makes it clear which
`Res` belongs to which namespace, but the `SmallVec` throws that
information away.
And code that operates on the `SmallVec` tends to use iteration (or even
just grabbing the first entry!) without knowing which namespace the
`Res` belongs to. Even weirder! Also, `SmallVec` is an overly flexible
type to use here, because it can contain any number of elements (even
though it's optimized for 3 in this case).
This commit changes `UsePath` so it also contains a
`PerNS<Option<Res<HirId>>>`. This type preserves more information and is
more self-documenting. The commit also changes a lot of the use sites to
access the result for a particular namespace. E.g. if you're looking up
a trait, it will be in the `Res` for the type namespace if it's present;
it's silly to look in the `Res` for the value namespace or macro
namespace. Overall I find the new code much easier to understand.
However, some use sites still iterate. These now use `present_items`
because that filters out the `None` results.
Also, `redundant_pub_crate.rs` gets a bigger change. A
`UseKind:ListStem` item gets no `Res` results, which means the old `all`
call in `is_not_macro_export` would succeed (because `all` succeeds on
an empty iterator) and the `ListStem` would be ignored. This is what we
want, but was more by luck than design. The new code detects `ListStem`
explicitly. The commit generalizes the name of that function
accordingly.
Finally, the commit also removes the `use_path` arena, because
`PerNS<Option<Res>>` impls `Copy` (unlike `SmallVec`) and it can be
allocated in the arena shared by all `Copy` types.
Fix TLS model on bootstrap for cygwin
There aren't other targets that both use emutls and enable `has_thread_local`, so cygwin triggers this bug first.
r? mati865
See: https://github.com/rust-lang/rust/pull/141719#issuecomment-2925445263
``@jeremyd2019`` Could you check if this PR fixes the issue? I just found my pre-built stage-0 rustc was too old to build the current rustc :(
Add unimplemented `current_dll_path()` for WASI
This is the only change needed to Rust to allow compiling rustfmt for WASI (rustfmt uses some internal rustc crates).
Drive-by refactor: use `OnceCell` for the reverse region SCC graph
During region inference, the reverse SCC region graph is sometimes computed lazily. This changes the implementation for that from using an `Option` to a `OnceCell` which clearly communicates the intention and simplifies the code somewhat.
There shouldn't be any performance impact, except that this pulls the computation of the reverse SCC graph slightly later than before, and so may avoid computing it in some instances.
Note that this changes a mutable reference into an immutable (interior mutable) one.
Exclude `CARGO_HOME` from `generate-copyright` in-tree determination
On Ferrocene, we noticed that in our releases the out-of-tree notices were not being included. When `x.py run generate-copyright` was ran on local development machines, it worked fine.
After some investigations ``@tshepang`` and I determined that the problem was that the cargo registry (located in `CARGO_HOME`) started with the source directory on CI jobs, and was being excluded by this line:
https://github.com/rust-lang/rust/blob/15825b7161f8bd6a3482211fbf6727a52aa1166b/src/tools/generate-copyright/src/cargo_metadata.rs#L85-L88
In Ferrocene's `run.sh` we set `CARGO_HOME` to be `build/cargo-home`: https://github.com/ferrocene/ferrocene/blob/96a45dd9a18c6e54d3cd81750a78fe459fa48af0/ferrocene/ci/run.sh#L34-L46 which caused this issue.
This PR passes the `CARGO_HOME` variable to the `generate-copyright` tool and expands the consideration of in-tree-ness to be aware of `CARGO_HOME`. It is an upstreaming of https://github.com/ferrocene/ferrocene/pull/1491.
## Testing
Run `CARGO_HOME=build/cargo-home ./x.py run generate-copyright` on `master`, then check `build/host/doc/COPYRIGHT` and look for out of tree dependencies (at the bottom).
Then, try running the same command in this branch.
source_span_for_markdown_range: fix utf8 violation
it is non-trivial to reproduce this bug through rustdoc, which uses this function less than clippy, so the regression test was added as a unit test instead of an integration test.
fixes https://github.com/rust-lang/rust/issues/141665
r? ``@GuillaumeGomez``
terminology: allocated object → allocation
Rust does not have "objects" in memory so "allocated object" is a somewhat odd name. I am not sure where the term comes from. "object" has been used to refer to allocations already [in 1.0 docs](https://doc.rust-lang.org/1.0.0/std/primitive.pointer.html#method.offset); this was apparently later changed to "allocated object".
"Allocation" is already the terminology used in Miri and in the [UCG](https://rust-lang.github.io/unsafe-code-guidelines/glossary.html#allocation). We should properly move to that terminology, and avoid any confusion about whether Rust has an object memory model. (It does not. Memory contains untyped bytes.)
Cc ``@rust-lang/opsem`` ``@rust-lang/lang``
Improve diagnostics for usage of qualified paths within tuple struct exprs/pats
For patterns the old diagnostic was just incorrect, but I also added machine applicable suggestions.
For context, this special cases errors for `<T as Trait>::Assoc(..)` patterns and expressions (latter is just a call). Tuple struct patterns and expressions both live in the value namespace, so they are not forwarded through associated *types*.
r? ``@jdonszelmann``
cc ``@petrochenkov`` in https://github.com/rust-lang/rust/pull/80080#issuecomment-800630582 you were wondering why it doesn't work for types, that's why — tuple patterns are resolved in the value namespace.
Miri subtree update
r? `@ghost`
Includes https://github.com/rust-lang/miri/pull/4370 to unbreak PR CI. (So we're committing to having bda28aa38 in the Miri history by landing this, whether or not that Miri PR lands.)
Cc `@Noratrieb` `@tiif`
Tokio `AsyncWriteExt::write` doesn't actually ensure that the contents
have written, it just *starts* the write operation. To ensure that the
file has actually been written, we need to `sync_all` first.
Tweak fast path trait handling
(1.) Make it more sound by considering polarity (lol)
(2.) Make it more general, by considering higher-ranked size/copy/clone
(2.) Make it less observable, by only doing copy/clone fast path if there are no regions involved
r? lcnr
The test did `write` and `read` and hoped that it would read/write
everything, which doesn't always happen and caused CI failures.
Switch to `write_all` and `read_to_end` to make it more reliable.
cstore: Use IndexSet as backing store for postorder dependencies
`<rustc_metadata::creader::CStore>::push_dependencies_in_postorder` showed up in new benchmarks from https://github.com/rust-lang/rustc-perf/pull/2143, hence I gave it a shot to remove an obvious O(n) there.
r? nnethercote
Fix "consider borrowing" for else-if
Fixesrust-lang/rust#141810
When trying to suggest a borrow on a `if` or `block` expression, instead we now recurse into the `if` or `block`.
The comments in the code should explain the goal of the new code.
r? ``@jdonszelmann``
Miri CI: test aarch64-apple-darwin in PRs instead of the x86_64 target
The aarch64 target is more important, and also this ensures we cover all main architectures (x86_64, i686, aarch64) in PR CI.
std: clarify Clone trait documentation about duplication semantics
Closesrust-lang/rust#141138
The change explicitly explains that cloning behavior varies by type and clarifies that smart pointers (`Arc`, `Rc`) share the same underlying data. I've also added an example of cloning to Arc.
`slice.get(i)` should use a slice projection in MIR, like `slice[i]` does
`slice[i]` is built-in magic, so ends up being quite different from `slice.get(i)` in MIR, even though they're both doing nearly identical operations -- checking the length of the slice then getting a ref/ptr to the element if it's in-bounds.
This PR adds a `slice_get_unchecked` intrinsic for `impl SliceIndex for usize` to use to fix that, so it no longer needs to do a bunch of lines of pointer math and instead just gets the obvious single statement. (This is *not* used for the range versions, since `slice[i..]` and `slice[..k]` can't use the mir Slice projection as they're using fenceposts, not indices.)
I originally tried to do this with some kind of GVN pattern, but realized that I'm pretty sure it's not legal to optimize `BinOp::Offset` to `PlaceElem::Index` without an extremely complicated condition. Basically, the problem is that the `Index` projection on a dereferenced slice pointer *cares about the metadata*, since it's UB to `PlaceElem::Index` outside the range described by the metadata. But then you cast the fat pointer to a thin pointer then offset it, that *ignores* the slice length metadata, so it's possible to write things that are legal with `Offset` but would be UB if translated in the obvious way to `Index`. Checking (or even determining) the necessary conditions for that would be complicated and error-prone, whereas this intrinsic-based approach is quite straight-forward.
Zero backend changes, because it just lowers to MIR, so it's already supported naturally by CTFE/Miri/cg_llvm/cg_clif.
In the previous description it said there was a TOCTOU race but did not
explain exactly what the problem was. I sat down with the CVE, reviewed
its text, and created this explanation. This context should hopefully
help people understand the actual risk as-such.
Incidentally, it also fixes the capitalization on the name of Redox OS.
it is non-trivial to reproduce this bug through rustdoc,
which uses this function less than clippy,
so the regression test was added as a unit test
instead of an integration test.
Add const support for the float rounding methods floor, ceil, trunc,
fract, round and round_ties_even.
This works by moving the calculation logic from
src/tools/miri/src/intrinsics/mod.rs
into
compiler/rustc_const_eval/src/interpret/intrinsics.rs.
All relevant method definitions were adjusted to include the `const`
keyword for all supported float types: f16, f32, f64 and f128.
The constness is hidden behind the feature gate
feature(const_float_round_methods)
which is tracked in
https://github.com/rust-lang/rust/issues/141555
This commit is a squash of the following commits:
- test: add tests that we expect to pass when float rounding becomes const
- feat: make float rounding methods `const`
- fix: replace `rustc_allow_const_fn_unstable(core_intrinsics)` attribute with `#[rustc_const_unstable(feature = "f128", issue = "116909")]` in `library/core/src/num/f128.rs`
- revert: undo update to `library/stdarch`
- refactor: replace multiple `float_<mode>_intrinsic` rounding methods with a single, parametrized one
- fix: add `#[cfg(not(bootstrap))]` to new const method tests
- test: add extra sign tests to check `+0.0` and `-0.0`
- revert: undo accidental changes to `round` docs
- fix: gate `const` float round method behind `const_float_round_methods`
- fix: remove unnecessary `#![feature(const_float_methods)]`
- fix: remove unnecessary `#![feature(const_float_methods)]` [2]
- revert: undo changes to `tests/ui/consts/const-eval/float_methods.rs`
- fix: adjust after rebase
- test: fix float tests
- test: add tests for `fract`
- chore: add commented-out `const_float_round_methods` feature gates to `f16` and `f128`
- fix: adjust NaN when rounding floats
- chore: add FIXME comment for de-duplicating float tests
- test: remove unnecessary test file `tests/ui/consts/const-eval/float_methods.rs`
- test: fix tests after upstream simplification of how float tests are run
Rollup of 8 pull requests
Successful merges:
- rust-lang/rust#140787 (Note expr being cast when encounter NonScalar cast error)
- rust-lang/rust#141112 (std: note that `std::str::from_utf8*` functions are aliases to `<str>::from_utf8*` methods)
- rust-lang/rust#141646 (Document what `distcheck` is intended to exercise)
- rust-lang/rust#141740 (Hir item kind field order)
- rust-lang/rust#141793 (`tests/ui`: A New Order [1/N])
- rust-lang/rust#141805 (Update `compiler-builtins` to 0.1.160)
- rust-lang/rust#141815 (Enable non-leaf Frame Pointers for mingw-w64 Arm64 Windows)
- rust-lang/rust#141819 (Fixes for building windows-gnullvm hosts)
r? `@ghost`
`@rustbot` modify labels: rollup
Enable non-leaf Frame Pointers for mingw-w64 Arm64 Windows
Based on https://github.com/rust-lang/rust/pull/140828
I don't have AArch64 Windows to test it, but I trust LLVM to handle it well.
`tests/ui`: A New Order [1/N]
not sure if i should say something about changes here, just part of rust-lang/rust#133895
but this is my very first time doing something like this, id love to keep contributing in this area later on, so any feedback is appreciated
also should say that im going to squash it after agreement on changes
r? `@jieyouxu`
mind if i name this PR series like "`tests/ui`: A New Order [N/N]", im not sure if it fits the project tone, so id like your approval first — but i think it sounds really neat (Star Wars reference)
this could be a first part :)
Note expr being cast when encounter NonScalar cast error
Fixes#140491
I added note for `expr` so that it doesn't treat `&x as T` as `&(x as T)` but `(&x) as T`. But I'm not sure if I want to add note for all NonScalar, maybe for specific `expr_ty`?
r? compiler
Nicholas Nethercote