| Age | Commit message (Collapse) | Author | Lines |
|---|
|
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...
|
|
const-eval: better wording for errors involving maybe-null pointers
Fixes https://github.com/rust-lang/rust/issues/146748
r? ``@oli-obk``
|
|
Make missed precondition-free float intrinsics safe
So, in my defence, these were both separated out from the other intrinsics in the file *and* had a different safety comment in the stable versions, so, I didn't notice them before. But, in my offence, the entire reason I did the previous PR was because I was using them for SIMD intrinsic fallbacks, and `fabs` is needed for those too, so, I don't really have an excuse.
Extra follow-up to rust-lang/rust#146683.
r? ```@RalfJung``` who reviewed the previous one
These don't appear to be used anywhere outside of the standard locations, at least.
|
|
revert change removing `has_infer` check. Commit conservatively patch…
…es for now, but more development proceeding.
Hotfix for rust-lang/rust#146852.
|
|
fix 2 borrowck issues
fixes https://github.com/rust-lang/rust/issues/146467 cc ``@amandasystems``
our understanding here is as follows: region constraints from computing implied bounds gets `ConstraintCategory::Internal`. If there's a higher-ranked subtyping errors while computing implied bounds we then ended up with only `ConstraintCategory::Internal` and `ConstraintCategory::OutlivesUnnameablePlaceholder(_)` constraints.
The path was something like
- `'placeholderU2: 'placeholderU1` (`Internal`)
- `'placeholderU1: 'static` (`OutlivesUnnameablePlaceholder('placeholderU2)`)
It's generally somewhat subtle here as ideally relating placeholders doesn't introduce `'static` constraints. Relating the placeholders themselves will always error regardless, cc https://github.com/rust-lang/rust/pull/142623.
---
separately fixes https://github.com/rust-lang/rust/pull/145925#issuecomment-3303733357 by updating the location for deferred closure requirements inside of promoteds. I am not updating their category as doing so is 1) effort and 2) imo actually undesirable :thinking: see the comments in `TypeChecker::check_promoted` cc ``@lqd``
r? lqd
|
|
r=Urgau,davidtwco
Extends AArch64 branch protection support to include GCS
Extends existing support for AArch64 branch protection to include support for [Guarded Control Stacks](https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/arm-a-profile-architecture-2022#guarded-control-stack-gcs:~:text=Extraction%20or%20tracking.-,Guarded%20Control%20Stack%20(GCS),-With%20the%202022).
|
|
|
|
outside the range of a scalar
|
|
Co-authored-by: Rémy Rakic <remy.rakic+github@gmail.com>
|
|
|
|
Fix a crash/mislex when more than one frontmatter closing possibility is considered
When the less fortunate recovery path for frontmatters are taken, if the lexer considers more than one possible frontmatter closing possibility, the current index is entirely mis-tracked and can result in bump_bytes landing in the middle of a multichar unicode character.
This fixes it by tracking the actual base index and updating it as it considers additional closing possibilities.
fixes rust-lang/rust#146847
|
|
now, but more development proceeding. Also contains a more concise test
|
|
mbe: Simplifications and refactoring
A few simplifications and refactors in advance of other work.
Macro metavariable expressions were using `Ident::as_str` and doing string
comparisons; I converted them to use symbols.
I factored out a function for transcribing a `ParseNtResult`, which will help
separate the evaluation and transcription of future macro metavariable
expressions.
|
|
Fix a dangling reference in `rustc_thread_pool`
This diverged from `rayon` in rust-lang/rust#142384, where a cleanup commit turned the matched `worker_index` into a reference, which is read _after_ the `set` that may kill it. I've moved that read beforehand, and I hope the new comments will emphasize the subtlety of this unsafe code.
Hopefully fixes rust-lang/rust#146677.
|
|
[win] Use find-msvc-tools instead of cc to find the linker and rc on Windows
`find-msvc-tools` was factored out from `cc` to allow updating the use in `rustc_codegen_ssa` (finding the linker when running the Rust compiler) and `rustc_windows_rc` (finding the Windows Resource Compiler when running the Rust compiler) to be separate from the use in `rustc_llvm` (building LLVM as part of building the Rust compiler).
|
|
fixes for numerous clippy warnings
|
|
Add panic=immediate-abort
MCP: https://github.com/rust-lang/compiler-team/issues/909
This adds a new panic strategy, `-Cpanic=immediate-abort`. This panic strategy essentially just codifies use of `-Zbuild-std-features=panic_immediate_abort`. This PR is intended to just set up infrastructure, and while it will change how the compiler is invoked for users of the feature, there should be no other impacts.
In many parts of the compiler, `PanicStrategy::ImmediateAbort` behaves just like `PanicStrategy::Abort`, because actually most parts of the compiler just mean to ask "can this unwind?" so I've added a helper function so we can say `sess.panic_strategy().unwinds()`.
The panic and unwind strategies have some level of compatibility, which mostly means that we can pre-compile the sysroot with unwinding panics then the sysroot can be linked with aborting panics later. The immediate-abort strategy is all-or-nothing, enforced by `compiler/rustc_metadata/src/dependency_format.rs` and this is tested for in `tests/ui/panic-runtime/`. We could _technically_ be more compatible with the other panic strategies, but immediately-aborting panics primarily exist for users who want to eliminate all the code size responsible for the panic runtime. I'm open to other use cases if people want to present them, but not right now. This PR is already large.
`-Cpanic=immediate-abort` sets both `cfg(panic = "immediate-abort")` _and_ `cfg(panic = "abort")`. bjorn3 pointed out that people may be checking for the abort cfg to ask if panics will unwind, and also the sysroot feature this is replacing used to require `-Cpanic=abort` so this seems like a good back-compat step. At least for the moment. Unclear if this is a good idea indefinitely. I can imagine this being confusing.
The changes to the standard library attributes are purely mechanical. Apart from that, I removed an `unsafe` we haven't needed for a while since the `abort` intrinsic became safe, and I've added a helpful diagnostic for people trying to use the old feature.
To test that `-Cpanic=immediate-abort` conflicts with other panic strategies, I've beefed up the core-stubs infrastructure a bit. There is now a separate attribute to set flags on it.
I've added a test that this produces the desired codegen, called `tests/run-make-cargo/panic-immediate-abort-codegen/` and also a separate run-make-cargo test that checks that we can build a binary.
|
|
|
|
considered
|
|
Rollup of 5 pull requests
Successful merges:
- rust-lang/rust#146795 (Enable `limit_rdylib_exports` on wasm targets)
- rust-lang/rust#146828 (fix a crash in rustdoc merge finalize without input file)
- rust-lang/rust#146848 (Add x86_64-unknown-motor (Motor OS) tier 3 target)
- rust-lang/rust#146884 (Fix modification check of `rustdoc-json-types`)
- rust-lang/rust#146887 (Remove unused #![feature(get_mut_unchecked)] in Rc and Arc examples)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Add x86_64-unknown-motor (Motor OS) tier 3 target
Add the initial no-std Motor OS compiler target.
Motor OS has been developed for several years in the open: https://github.com/moturus/motor-os.
It has a more or less full implementation of Rust std library, as well as tokio/mio ports.
> A tier 3 target must have a designated developer or developers (the "target maintainers") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.)
Ack. [U. Lasiotus](https://github.com/lasiotus) will maintain the target.
> Targets must use naming consistent with any existing targets; for instance, a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains), unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive, especially once the target reaches a higher tier, so getting the name right is important even for a tier 3 target.
> Target names should not introduce undue confusion or ambiguity unless absolutely necessary to maintain ecosystem compatibility. For example, if the name of the target makes people extremely likely to form incorrect beliefs about what it targets, the name should be changed or augmented to disambiguate it.
> If possible, use only letters, numbers, dashes and underscores for the name. Periods (.) are known to cause issues in Cargo.
Ack. The new target is named `x86_64-unknown-motor`, as it represents Motor OS on x86_64.
> Tier 3 targets may have unusual requirements to build or use, but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users.
> The target must not introduce license incompatibilities.
> Anything added to the Rust repository must be under the standard Rust license (MIT OR Apache-2.0).
> The target must not cause the Rust tools or libraries built for any other host (even when supporting cross-compilation to the target) to depend on any new dependency less permissive than the Rust licensing policy. This applies whether the dependency is a Rust crate that would require adding new license exceptions (as specified by the tidy tool in the rust-lang/rust repository), or whether the dependency is a native library or binary. In other words, the introduction of the target must not cause a user installing or running a version of Rust or the Rust tools to be subject to any new license requirements.
Ack. Motor OS is dual-licensed under MIT and/or Apache-2.0.
> Compiling, linking, and emitting functional binaries, libraries, or other code for the target (whether hosted on the target itself or cross-compiling from another target) must not depend on proprietary (non-FOSS) libraries. Host tools built for the target itself may depend on the ordinary runtime libraries supplied by the platform and commonly used by other applications built for the target, but those libraries must not be required for code generation for the target; cross-compilation to the target must not require such libraries at all. For instance, rustc built for the target may depend on a common proprietary C runtime library or console output library, but must not depend on a proprietary code generation library or code optimization library. Rust's license permits such combinations, but the Rust project has no interest in maintaining such combinations within the scope of Rust itself, even at tier 3.
> "onerous" here is an intentionally subjective term. At a minimum, "onerous" legal/licensing terms include but are not limited to: non-disclosure requirements, non-compete requirements, contributor license agreements (CLAs) or equivalent, "non-commercial"/"research-only"/etc terms, requirements conditional on the employer or employment of any particular Rust developers, revocable terms, any requirements that create liability for the Rust project or its developers or users, or any requirements that adversely affect the livelihood or prospects of the Rust project or its developers or users.
> Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target, or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target, they must recuse themselves from any approval decisions regarding the target's tier status, though they may otherwise participate in discussions.
> This requirement does not prevent part or all of this policy from being cited in an explicit contract or work agreement (e.g. to implement or maintain support for a target). This requirement exists to ensure that a developer or team responsible for reviewing and approving a target does not face any legal threats or obligations that would prevent them from freely exercising their judgment in such approval, even if such judgment involves subjective matters or goes beyond the letter of these requirements.
Ack.
> Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets, alloc for targets that can support dynamic memory allocation, std for targets with an operating system or equivalent layer of system-provided functionality), but may leave some code unimplemented (either unavailable or stubbed out as appropriate), whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions.
Motor OS has a functional implementation of the standard library: https://github.com/moturus/rust/tree/motor-os_stdlib, which will be the subject of a later PR.
> The target must provide documentation for the Rust community explaining how to build for the target, using cross-compilation if possible. If the target supports running binaries, or running tests (even if they do not pass), the documentation must explain how to run such binaries or tests for the target, using emulation if possible or dedicated hardware if necessary.
Building instructions for Motor OS: https://github.com/moturus/motor-os/blob/main/docs/build.md.
> Tier 3 targets must not impose burden on the authors of pull requests, or other developers in the community, to maintain the target. In particular, do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium, including via `@)` to a PR author or others involved with a PR regarding a tier 3 target, unless they have opted into such messages.
Ack.
> Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy, within reason. However, such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications.
> Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target, and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target.
> In particular, this may come up when working on closely related targets, such as variations of the same architecture with different features. Avoid introducing unconditional uses of features that another variation of the target may not have; use conditional compilation or runtime detection, as appropriate, to let each target run code supported by that target.
Ack.
> Tier 3 targets must be able to produce assembly using at least one of rustc's supported backends from any host target. (Having support in a fork of the backend is not sufficient, it must be upstream.)
Motor OS uses the standard x86_64 rustc/llvm toolchain.
> If a tier 3 target stops meeting these requirements, or the target maintainers no longer have interest or time, or the target shows no signs of activity and has not built for some time, or removing the target would improve the quality of the Rust codebase, we may post a PR to remove it; any such PR will be CCed to the target maintainers (and potentially other people who have previously worked on the target), to check potential interest in improving the situation.
Ack.
|
|
Enable `limit_rdylib_exports` on wasm targets
This commit updates the target specification of wasm targets to set the `limit_rdylib_exports` value to `true` like it is on other native platforms. This was originally not implemented long ago as `wasm-ld` didn't have options for symbol exports, but since then it's grown a `--export` flag and such to control this. A custom case is needed in the linker implementation to handle wasm targets as `wasm-ld` doesn't support linker scripts used on other targets, but other than that the implementation is straightforward.
The goal of this commit is enable building dynamic libraries on `wasm32-wasip2` which don't export every single symbol in the Rust standard library. Currently, without otherwise control over symbol visibility, all symbols end up being exported which generates excessively large binaries because `--gc-sections` ends up doing nothing as it's all exported anyway.
|
|
Mark float intrinsics with no preconditions as safe
Note: for ease of reviewing, the list of safe intrinsics is sorted in the first commit, and then safe intrinsics are added in the second commit.
All *recently added* float intrinsics have been correctly marked as safe to call due to the fact that they have no preconditions. This adds the remaining float intrinsics which are safe to call to the safe intrinsic list, and removes the unsafe blocks around their calls.
---
Side note: this may want a try run before being added to the queue, since I'm not sure if there's any tier-2 code that uses these intrinsics that might not be tested on the usual PR flow. We've already uncovered a few places in subtrees that do this, and it's worth double-checking before clogging up the queue.
|
|
Make mips64el-unknown-linux-muslabi64 link dynamically
I missed this target when I changed all the other tier 3 targets in https://github.com/rust-lang/rust/pull/144410. Only realized that this one was still statically linked when I looked at the list of targets in the test later (https://github.com/rust-lang/rust/pull/146588).
since those two PRs were reviewed by you:
r? ````@jieyouxu````
|
|
Add self-profile events for target-machine creation
These code paths are surprisingly hot in the `large-workspace` benchmark (e.g. see perf changes from rust-lang/rust#146700), suggesting room for more improvement. It would be handy to see some detailed timings and execution counts.
|
|
Support ctr and lr as clobber-only registers in PowerPC inline assembly
Follow-up to rust-lang/rust#131341.
CTR and LR are marked as volatile in all ABIs, but I skipped them in rust-lang/rust#131341 due to they are currently marked as reserved.
https://github.com/rust-lang/rust/blob/dd7fda570040e8a736f7d8bc28ddd1b444aabc82/compiler/rustc_target/src/asm/powerpc.rs#L209-L212
However, they are actually only unusable as input/output of inline assembly, and should be fine to support as clobber-only registers as discussed in [#t-compiler > ppc/ppc64 inline asm support](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/ppc.2Fppc64.20inline.20asm.20support/with/540413845).
r? ````@Amanieu```` or ````@workingjubilee````
cc ````@programmerjake````
````@rustbot```` label +O-PowerPC +A-inline-assembly
|
|
emit attribute for readonly non-pure inline assembly
fixes https://github.com/rust-lang/rust/issues/146761
Provide a better `MemoryEffects` to LLVM when an inline assembly block specifies `readonly` but not `pure`. That means that the assembly block may not perform any writes, but that there still may be side effects from its instructions.
I haven't been able to find a case yet where this actually matters, though. So the test checks that the right attribute is applied, but the generated assembly is equivalent to not specifying `readonly` at all.
r? ````@nikic````
cc ````@Amanieu````
|
|
|
|
Port #[macro_export] to the new attribute parsing infrastructure
Ports macro_export to the new attribute parsing infrastructure for https://github.com/rust-lang/rust/issues/131229#issuecomment-2971353197
r? ``@oli-obk``
cc ``@JonathanBrouwer`` ``@jdonszelmann``
|
|
Add the initial no-std Motor OS compiler target.
Motor OS has been developed for several years in the open:
https://github.com/moturus/motor-os.
It has a more or less full implementation of Rust std library,
as well as tokio/mio ports.
Build instructions can be found here:
https://github.com/moturus/motor-os/blob/main/docs/build.md.
Signed-off-by: U. Lasiotus <lasiotus@motor-os.org>
|
|
|
|
I missed this target when I changed all the other tier 3 targets. Only
realized that this one was still statically linked when I looked at the
list of targets in the test later.
Signed-off-by: Jens Reidel <adrian@travitia.xyz>
|
|
|
|
|
|
|
|
Consider errors in MIR as impossible predicates to empty the body.
The ICEs come from elaborating drops or performing state transform in MIR bodies that fail typeck or borrowck.
If the body is tainted, replace it with `unreachable`.
Fixes https://github.com/rust-lang/rust/issues/122630
Fixes https://github.com/rust-lang/rust/issues/122904
Fixes https://github.com/rust-lang/rust/issues/125185
Fixes https://github.com/rust-lang/rust/issues/139556
|
|
Co-authored-by: Anne Stijns <anstijns@gmail.com>
|
|
These code paths are surprisingly hot in the `large-workspace` benchmark; it
would be handy to see some detailed timings and execution counts.
|
|
|
|
naked_asm: emit a label starting with `func_end`
The `cargo asm` tool (`cargo install cargo-show-asm`) pattern matches on such labels to figure out where functions end: normal functions generated by LLVM always do have such a label. We don't guarantee that naked functions emit such a label, but having `cargo asm` work is convenient.
https://github.com/pacak/cargo-show-asm/blob/be45f67454ad8b634246a7fc69b3c6a963ee93f1/src/asm/statements.rs#L897-L901
To make the label name unique it's suffixed with the name of the current symbol.
r? ```@Amanieu```
|
|
Deref related cleanups in ref_prop
Cherry picked from rust-lang/rust#146710
r? cjgillot
|
|
fix issue with `cmse-nonsecure-entry` ABI being both async and c-variadic
tracking issue: https://github.com/rust-lang/rust/issues/75835
fixes https://github.com/rust-lang/rust/issues/132142
An `extern "cmse-nonsecure-entry"` function cannot be c-variadic (or, in any case, clang/LLVM does not support it, see https://godbolt.org/z/MaPjzGcE1). So just stop looking at the type if we know it'll be invalid anyway.
I'm not entirely sure how to test this. The ICE is only possible on the `thumbv8m.main-none-eabi` and some related targets. I think using `minicore` is the most convenient, but use of `async` requires quite a long list of lang items to be present. Maybe we want that anyway though? On the other hand, it's extra `minicore` surface that might go out of date.
An alternative is `run-make`, that should work, but is much less convenient. See also [#t-compiler/help > `async fn` and `minicore`](https://rust-lang.zulipchat.com/#narrow/channel/182449-t-compiler.2Fhelp/topic/.60async.20fn.60.20and.20.60minicore.60/with/539427262).
r? `@ghost`
|
|
Stabilize `new_zeroed_alloc`
The corresponding `new_uninit` and `new_uninit_slice` functions were stabilized in rust-lang/rust#129401, but the zeroed counterparts were left for later out of a [desire](https://github.com/rust-lang/rust/issues/63291#issuecomment-2161039756) to stabilize only the minimal set. These functions are straightforward mirrors of the uninit functions and well-established. Since no blockers or design questions have surfaced in the past year, I think it's time to stabilize them.
Tracking issue: rust-lang/rust#129396
|
|
|
|
fixes for numerous clippy warnings
|
|
generate list of all variants with `target_spec_enum`
This helps us avoid the hardcoded lists elsewhere.
r? ``@Noratrieb``
|
|
Identify metavariable functions by using named symbols rather than
string comparisons.
|
|
|
|
Factor out the check for a variable that's still repeating.
|
|
This helps us avoid the hardcoded lists elsewhere.
|
