| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Stop linking rs{begin,end} objects on x86_64-*-windows-gnu
Until now, x86_64-pc-windows-gnu linked `rsbegin.o` and `rsend.o` just like i686-pc-windows-gnu, even though they were no-ops for it. This was likely done for the simplicity back when it was introduced.
Today the things are different and these startup/end objects harm other features, like `build-std`. Given the demotion of i686-pc-windows-gnu from tier 1, there is no point in hurting x86_64-pc-windows-gnu, which remains a tier 1.
The files are still shipped in case downstream crates expect them, as in case of the unmaintained `xargo`.
Fixes https://github.com/rust-lang/rust/issues/146739
|
|
port `#[debugger_visualizer]` to the new attribute system
|
|
Demote both armebv7r-none-* targets.
OK, slightly more controversial than https://github.com/rust-lang/rust/pull/146520 and https://github.com/rust-lang/rust/pull/146522 - I'd like to drop the bare-metal **big-endian** Armv7-R targets down to Tier 3.
The reason is simple - we cannot test them in https://github.com/rust-embedded/cortex-ar/. This because QEMU support for Big Endian Armv7-R is broken. I tried quite hard, but all the strings I printed with semihosting came out byte swapped (or "etybawa depp") because of how QEMU kludges the access to memory in big-endian mode.
The target also has only a single maintainer. Although, if ````@chrisnc```` wants to put up a case for keeping it at Tier 2 though, I'm happy to hear it!
This PR wil be rebased once https://github.com/rust-lang/rust/pull/146419 completes the queue.
|
|
resolve: Do not finalize shadowed bindings
I.e. do not mark them as used, or non-speculatively loaded, or similar.
Previously they were sometimes finalized during early resolution, causing issues like https://github.com/rust-lang/rust/pull/144793#issuecomment-3168108005.
|
|
|
|
|
|
We'll still error due to the `opt_bad_ty` of `method_autoderef_steps`.
This slightly worsens the span of `infer_var.method()` which is now the
same as for `Box::new(infer_var).method()`.
Unlike `structurally_resolve_type`, `probe_op` does not check whether
the infcx is already tainted, so this results in 2 previously not emitted
errors.
|
|
`autoderef` already resolved and `method_autoderef_steps` makes
sure we won't encounter an inference variable
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Rollup of 7 pull requests
Successful merges:
- rust-lang/rust#146283 (Resolve: (Ref)Cell wrappers to deny mutation during spec resolution.)
- rust-lang/rust#146453 (Add general arm-linux.md platform doc.)
- rust-lang/rust#146991 (const_caller_location to use real Span instead of `DUMMY_SP`)
- rust-lang/rust#146994 (Add `clippy::unconditional_recursion` to `./x clippy ci`)
- rust-lang/rust#147038 (Rename verbosity functions in bootstrap)
- rust-lang/rust#147047 (rustdoc: put the toolbar on the all item index)
- rust-lang/rust#147049 (std: fix warning in VEXos stdio module)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
const_caller_location to use real Span instead of `DUMMY_SP`
Clarifying usage of DUMMY_SP
|
|
Resolve: (Ref)Cell wrappers to deny mutation during spec resolution.
Introduces wrappers around `Cell` and `RefCell` that only allow mutation when we are not in speculative resolution. This is preparatory work for rust-lang/rust#145108.
It would allow us to make `ImportData` and `ModuleData` sync and send safe.
r? ``@petrochenkov``
|
|
Extended temporary argument to format_args!() in all cases
Fixes https://github.com/rust-lang/rust/issues/145880 by removing the special case.
|
|
|
|
remove incorrect fast path
Using `tcx.is_copy_modulo_regions` drops information from the current `typing_env`. Writing a regression test for this is really hard. We need to prove `Copy` of something that doesn't directly reference a coroutine or an opaque, but does so indirectly.
cc rust-lang/rust#146813.
|
|
This changed in upstream change a5569b4bd7f8.
@rustbot label llvm-main
|
|
Rollup of 8 pull requests
Successful merges:
- rust-lang/rust#116882 (rustdoc: hide `#[repr]` if it isn't part of the public ABI)
- rust-lang/rust#135771 ([rustdoc] Add support for associated items in "jump to def" feature)
- rust-lang/rust#141032 (avoid violating `slice::from_raw_parts` safety contract in `Vec::extract_if`)
- rust-lang/rust#142401 (Add proper name mangling for pattern types)
- rust-lang/rust#146293 (feat: non-panicking `Vec::try_remove`)
- rust-lang/rust#146859 (BTreeMap: Don't leak allocators when initializing nodes)
- rust-lang/rust#146924 (Add doc for `NonZero*` const creation)
- rust-lang/rust#146933 (Make `render_example_with_highlighting` return an `impl fmt::Display`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Co-authored-by: Ralf Jung <post@ralfj.de>
|
|
I.e. do not mark them as used, or non-speculative loaded, or similar.
Previously they were sometimes finalized during early resolution, causing issues like https://github.com/rust-lang/rust/pull/144793#issuecomment-3168108005.
|
|
Avoid invalidating CFG caches from MirPatch::apply.
Small effort to reduce invalidating CFG caches.
|
|
|
|
Add proper name mangling for pattern types
requires adding demangler support first https://github.com/rust-lang/rustc-demangle/pull/81
needed for https://github.com/rust-lang/rust/pull/136006#discussion_r2139792593 as otherwise we will have symbol collisions
|
|
|
|
Eliminate a use of `map_or` in favor of a match.
Inline some variable definitions that don't add clarity, and that
prevent short-circuiting.
|
|
Several functions had comments referencing a non-existent `valid`
parameter. Remove those. The `guar` parameter that handles errors is
already documented.
In the process, remove another duplicate reference to an
already-documented parameter (`binders`).
|
|
Rollup of 14 pull requests
Successful merges:
- rust-lang/rust#145067 (RawVecInner: add missing `unsafe` to unsafe fns)
- rust-lang/rust#145277 (Do not materialise X in [X; 0] when X is unsizing a const)
- rust-lang/rust#145973 (Add `std` support for `armv7a-vex-v5`)
- rust-lang/rust#146667 (Add an attribute to check the number of lanes in a SIMD vector after monomorphization)
- rust-lang/rust#146735 (unstably constify float mul_add methods)
- rust-lang/rust#146737 (f16_f128: enable some more tests in Miri)
- rust-lang/rust#146766 (Add attributes for #[global_allocator] functions)
- rust-lang/rust#146905 (llvm: update remarks support on LLVM 22)
- rust-lang/rust#146982 (Remove erroneous normalization step in `tests/run-make/linker-warning`)
- rust-lang/rust#147005 (Small string formatting cleanup)
- rust-lang/rust#147007 (Explicitly note `&[SocketAddr]` impl of `ToSocketAddrs`)
- rust-lang/rust#147008 (bootstrap.py: Respect build.jobs while building bootstrap tool)
- rust-lang/rust#147013 (rustdoc: Fix documentation for `--doctest-build-arg`)
- rust-lang/rust#147015 (Use `LLVMDisposeTargetMachine`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Use `LLVMDisposeTargetMachine`
After bumping the minimum LLVM version to 20 (rust-lang/rust#145071), we no longer need to run any custom code when disposing of a TargetMachine, so we can just use the upstream LLVM-C function.
|
|
r=jdonszelmann
Small string formatting cleanup
This PR is mostly useless. I was going through this file, saw that and corrected it. That's pretty much it. Feel free to close it if it's a bother.
|
|
llvm: update remarks support on LLVM 22
LLVM change dfbd76bda01e removed separate remark support entirely, but
it turns out we can just drop the parameter and everything appears to
work fine.
Fixes rust-lang/rust#146912 as far as I can tell (the test passes.)
|
|
Add attributes for #[global_allocator] functions
Emit `#[rustc_allocator]` etc. attributes on the functions generated by the `#[global_allocator]` macro, which will emit LLVM attributes like `"alloc-family"`. If the module with the global allocator participates in LTO, this ensures that the attributes typically emitted on the allocator declarations are not lost if the definition is imported.
There is a similar issue when the allocator shim is used, but I've opted not to fix that case in this PR, because doing that cleanly is somewhat gnarly.
Related to https://github.com/rust-lang/rust/issues/145995.
|
|
unstably constify float mul_add methods
Tracking issue: rust-lang/rust#146724
r? `@tgross35`
|
|
Add an attribute to check the number of lanes in a SIMD vector after monomorphization
Allows std::simd to drop the `LaneCount<N>: SupportedLaneCount` trait and maintain good error messages.
Also, extends rust-lang/rust#145967 by including spans in layout errors for all ADTs.
r? ``@RalfJung``
cc ``@workingjubilee`` ``@programmerjake``
|
|
Add `std` support for `armv7a-vex-v5`
This PR adds standard library support for the VEX V5 Brain (`armv7a-vex-v5` target). It is more-or-less an updated version of the library-side work done in rust-lang/rust#131530.
This was a joint effort between me, `@lewisfm,` `@max-niederman,` `@Gavin-Niederman` and several other members of the [`vexide` project](https://github.com/vexide/).
## Background
VEXos is a fairly unconventional operating system, with user code running in a restricted enviornment with regards to I/O capabilities and whatnot. As such, several OS-dependent APIs are unsupported or have partial support (such as `std::net`, `std::process`, and most of `std::thread`). A more comprehensive list of what does or doesn't work is outlined in the [updated target documentation](https://github.com/vexide/rust/blob/vex-std/src/doc/rustc/src/platform-support/armv7a-vex-v5.md). Despite these limitations, we believe that `libstd` support on this target still has value to users, especially given the popular use of this hardware for educational purposes. For some previous discussion on this matter, see [this comment](https://github.com/rust-lang/rust/pull/131530#issuecomment-2432856841).
## SDK Linkage
VEXos doesn't really ship with an official `libc` or POSIX-style platform API (and though it does port newlib, these are stubbed on top of the underlying SDK). Instead, VEX provides their own SDK for calling platform APIs. Their official SDK is kept proprietary (with public headers), though open-source implementations exist. Following the precedent of the `armv6k-nintendo-3ds` team's work in rust-lang/rust#95897, we've opted not to directly link `libstd` to any SDK with the expectation that users will provide their own with one of the following options:
- [`vex-sdk-download`](https://github.com/vexide/vex-sdk/tree/main/packages/vex-sdk-download), which downloads an official proprietary SDK from VEX using a build script.
- [`vex-sdk-jumptable`](https://crates.io/crates/vex-sdk-jumptable), which is a compatible, open-source reimplementation of the SDK using firmware jumps.
- [`vex-sdk-pros`](https://github.com/vexide/vex-sdk/tree/main/packages/vex-sdk-pros), which uses the [PROS kernel](https://github.com/purduesigbots/pros) as a provider for SDK functions.
- Linking their own implementation or stubbing the functions required by libstd.
The `vex-sdk` crate used in the VEXos PAL provides `libc`-style FFI bindings for any compatible system library, so any of these options *should* work fine. A functional demo project using `vex-sdk-download` can be found [here](https://github.com/vexide/armv7a-vex-v5-demo/tree/main).
## Future Work
This PR implements virtually everything we are currently able to implement given the current capabilities of the platform. The exception to this is file directory enumeration, though the implementation of that is sufficiently [gross enough](https://github.com/vexide/vexide/blob/c6c5bad11e035cf4e51d429dca7e427210185ed4/packages/vexide-core/src/fs/mod.rs#L987) to drive us away from supporting this officially.
Additionally, I have a working branch implementing the `panic_unwind` runtime for this target, which is something that would be nice to see in the future, though given the volume of compiler changes i've deemed it out-of-scope for this PR.
|
|
r=nnethercote
Do not materialise X in [X; 0] when X is unsizing a const
Fix rust-lang/rust#143671
It turns out that MIR builder materialise `X` in `[X; 0]` into a temporary local when `X` is unsizing a `const`. This led to a confusing call to destructor of `X` when such a destructor is declared. [Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2024&gist=8dfc933af89efeb89c881bc77498ba63)
This patch may miss out other cases that we should avoid materialisation in case of `[X; 0]`. Suggestions to include is most welcome!
|
|
Rollup of 7 pull requests
Successful merges:
- rust-lang/rust#146556 (Fix duration_since panic on unix when std is built with integer overflow checks)
- rust-lang/rust#146679 (Clarify Display for error should not include source)
- rust-lang/rust#146753 (Improve the pretty print of UnstableFeature clause)
- rust-lang/rust#146894 (Improve derive suggestion of const param)
- rust-lang/rust#146950 (core: simplify `CStr::default()`)
- rust-lang/rust#146958 (Fix infinite recursion in Path::eq with String)
- rust-lang/rust#146971 (fix ICE in writeback due to bound regions)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
Use llfn_attrs_from_instance() to generate the attributes for the
allocator shim. This ensures that we generate all the usual
attributes (and don't get to find out one-by-one that a certain
attribute is important for a certain target). Additionally this
will enable emitting the allocator-specific attributes (not
included here).
This change is quite awkward because the allocator shim uses
SimpleCx, while llfn_attrs_from_instance uses CodegenCx. I've
switched it to use SimpleCx plus tcx/sess arguments where necessary.
If there's a simpler way to do this, I'd love to know about it...
|
|
|
|
|
|
fix ICE in writeback due to bound regions
fixes rust-lang/rust#117808
r? `@BoxyUwU`
|
|
Improve derive suggestion of const param
Make the suggestion not to remove the adt and use the name of the adt variant in the diagnostic.
r? `@BoxyUwU`
|
|
Improve the pretty print of UnstableFeature clause
As per https://github.com/rust-lang/rust/pull/145095#discussion_r2349439492, we could make the diagnostic for unsatisfiable ``UnstableFeature`` clause better.
r? `@BoxyUwU`
|
|
This improves the case where someone tries to write a `match` expr where the patterns have type ascription syntax. Makes them less verbose, by giving up on the first encounter in the block, and makes them more accurate by only treating them as a struct literal if successfuly parsed as such.
|
|
Co-authored-by: Ralf Jung <post@ralfj.de>
|
|
const-eval: better wording for errors involving maybe-null pointers
Fixes https://github.com/rust-lang/rust/issues/146748
r? ``@oli-obk``
|
