Add armv4t-none-eabi take2
This is the same as the previous PR (https://github.com/rust-lang/rust/pull/99226) but i just made a fresh branch without a merge commit in it.
---
### armv4t-none-eabi target quiz
> 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.
That's me!
> Targets must use naming consistent with any existing targets
We're using the existing name as recognized by LLVM and GCC
> 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.
No legal issues here.
>> The target must not introduce license incompatibilities.
No license requirements here.
>> Anything added to the Rust repository must be under the standard Rust license (MIT OR Apache-2.0).
check
>> 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.
no new deps, we're just adding a rustc target description file for a target llvm already knows about.
>> 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.
bare-metal target, doesn't rely on any libs at all.
> Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate
`core` only here. You could build `alloc` too, but you'd have to bring your own global allocator.
> The target must provide documentation for the Rust community explaining how to build for the target, using cross-compilation if possible.
LLVM knows how to do it, you just need the GNU Binutils linker because LLVM's linker doesn't work that far back. That's in the docs as part of this PR.
> Tier 3 targets must not impose burden on the authors of pull requests, or other developers in the community, to maintain the target.
No burdens, LLVM already knows how to do this. Further, because this is a cpu-feature variant of an existing tier3 target the `compiler-builtins` crate has already been updated as necessary to fix any missing builtin function gaps.
> 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.
check.
Use start_point instead of next_point to point to elided lifetime amp…
Using `next_point` creates a span which points inside the multibyte token, ICEing.
Fixes https://github.com/rust-lang/rust/issues/100224
Multiple duplicate assignments of the same discriminant are now reported
in the samme error. We now point out the incrementation start point for
discriminants that are not explicitly assigned that are also duplicates.
Removed old test related to E0081 that is now covered by error-codes/E0081.rs.
Also refactored parts of the `check_enum` function.
When an item isn't found, we may suggest an appropriate import to
`use`. Along with that, we also suggest updating the path to work
with the `use`. Unfortunately, if the code in question originates
from a macro, the span used to indicate which part of the path
needs updating may not be suitable and cause an ICE. Since, such
code is not adjustable directly by the user without modifying the
macro, just skip the suggestion in such cases.
Check link ordinal to make sure it is targetted for foreign function
Fix#100009, when link ordinal is not target for foreign functions, emit an error.
cc `@dpaoliello`
Avoid pointing out `return` span if it has nothing to do with type error
This code:
```rust
fn f(_: String) {}
fn main() {
let x = || {
if true {
return ();
}
f("");
};
}
```
Emits this:
```
Compiling playground v0.0.1 (/playground)
error[E0308]: mismatched types
--> src/main.rs:8:11
|
8 | f("");
| ^^- help: try using a conversion method: `.to_string()`
| |
| expected struct `String`, found `&str`
|
note: return type inferred to be `String` here
--> src/main.rs:6:20
|
6 | return ();
| ^^
```
Specifically, that note has nothing to do with the type error in question. This is because the change implemented in #84244 tries to point out the `return` span on _any_ type coercion error within a closure that happens after a `return` statement, regardless of if the error has anything to do with it.
This is really easy to trigger -- just needs a closure (or an `async`) and an early return (or any other form, e.g. `?` operator suffices) -- and super distracting in production codebases. I'm letting #84128 regress because that issue is much harder to fix correctly, and I can re-open that issue after this lands.
As a drive-by, I added a `resolve_vars_if_possible` to the coercion error logic, which leads to some error improvements. Unrelated to the issue above, though.
Rollup of 4 pull requests
Successful merges:
- #100094 (Detect type mismatch due to loop that might never iterate)
- #100132 (Use (actually) dummy place for let-else divergence)
- #100167 (Recover `require`, `include` instead of `use` in item)
- #100193 (Remove more Clean trait implementations)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Detect type mismatch due to loop that might never iterate
When loop as tail expression causes a miss match type E0308 error, recursively get the return statement and add diagnostic information on it.
Temporaries created with `MirPatch::new_temp` will be declared after
patch application. Remove manually created duplicate declarations.
Removing duplicates exposes another issue. Visitor elaborates
terminator twice and attempts to access new, but not yet available,
local declarations. Remove duplicated call to `visit_terminator`.
Enable function merging when opt is for size
It is, of course, natural to want to merge aliasing functions when
optimizing for code size, since that can eliminate several bytes.
And an exhaustive match helps make the code less brittle.
Closes#98215.
It is, of course, natural to want to merge aliasing functions when
optimizing for code size, since that can eliminate several bytes.
And an exhaustive match helps make the code less brittle.
when loop as tail expression for miss match type E0308 error, recursively get
the return statement and add diagnostic information on it
use rustc_hir::intravisit to collect the return expression
modified: compiler/rustc_typeck/src/check/coercion.rs
new file: src/test/ui/typeck/issue-98982.rs
new file: src/test/ui/typeck/issue-98982.stderr
Improve diagnostics for `const a: = expr;`
Adds a suggestion to write a type when there is a colon, but the type is not present.
I've also shrunk spans a little, so the suggestions are a little nicer.
Resolves#100146
r? `@compiler-errors`
Add test for raw-dylib with an external variable
All existing tests of link kind `raw-dylib` only validate the ability to link against functions, but it is also possible to link against variables.
This adds tests for linking against a variable using `raw-dylib` both by-name and by-ordinal.
Warn about dead tuple struct fields
Continuation of #92972. Fixes#92790.
The language team has already commented on this in https://github.com/rust-lang/rust/pull/92972#issuecomment-1021511970; I have incorporated their requests here. Specifically, there is now a new allow-by-default `unused_tuple_struct_fields` lint (name bikesheddable), and fields of unit type are ignored (https://github.com/rust-lang/rust/pull/92972#issuecomment-1021815408), so error messages look like this:
```
error: field is never read: `1`
--> $DIR/tuple-struct-field.rs:6:21
|
LL | struct Wrapper(i32, [u8; LEN], String);
| ^^^^^^^^^
|
help: change the field to unit type to suppress this warning while preserving the field numbering
|
LL | struct Wrapper(i32, (), String);
| ~~
```
r? `@joshtriplett`
Split create_def and lowering of lifetimes for opaque types and bare async fns
r? `@cjgillot`
This work is kind of half-way, but I think it could be merged anyway.
I think we should be able to remove all the vacant arms in `new_named_lifetime_with_res`, if I'm not wrong that requires visiting more nodes. We can do that as a follow up.
In follow-up PRs, besides the thing mentioned previously, I'll be trying to remove `LifetimeCaptureContext`, `captured_lifetimes` as a global data structure, global `binders_to_ignore` and all their friends :).
Also try to remap in a more general way based on def-ids.
Enable unused_parens for match arms
Fixes: https://github.com/rust-lang/rust/issues/92751
Currently I can't get the `stderr` to work with `./x.py test`, but this should fix the issue. Help would be appreciated!
Avoid invalidating the CFG in `MirPatch`
As a part of this change, we adjust `MirPatch` to not needlessly create unnecessary resume blocks.
r? `@tmiasko`
Always create elided lifetimes, even if inferred.
`PathSource` gives the context in which a path is encountered. The same `PathSource` is used for the full path and the `QSelf` part.
Therefore, we can only rely on `PathSource` to know whether typechecking will be able to infer the lifetimes, not whether we need to insert them at all.
Fixes https://github.com/rust-lang/rust/issues/99949
Some `is_useful` cleanups
#98582 was reverted because it was a perf regression.
https://github.com/rust-lang/rust/pull/99806 reintroduces the changes, but this PR picks individual ones that have no regressions.
Rollup of 6 pull requests
Successful merges:
- #98771 (Add support for link-flavor rust-lld for iOS, tvOS and watchOS)
- #98835 (relate `closure_substs.parent_substs()` to parent fn in NLL)
- #99746 (Use `TraitEngine` in more places that don't specifically need `FulfillmentContext::new_in_snapshot`)
- #99786 (Recover from C++ style `enum struct`)
- #99795 (Delay a bug when failed to normalize trait ref during specialization)
- #100029 (Prevent ICE for `doc_alias` on match arm, statement, expression)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Prevent ICE for `doc_alias` on match arm, statement, expression
Fixes#99777.
This is a pretty minimal fix that should be safe, since rustdoc doesn't generate documentation for match arms, statements, or expressions. I mentioned in the linked issue that the `doc_alias` target checking should probably be improved to avoid future ICEs, but as a new contributor, I'm not confident enough with the HIR types to make a larger change.
Delay a bug when failed to normalize trait ref during specialization
The error messages still kinda suck here but they don't ICE anymore...
Fixes#45814Fixes#43037
r? types
Use `TraitEngine` in more places that don't specifically need `FulfillmentContext::new_in_snapshot`
Not sure if this change is worthwhile, but couldn't hurt re: chalkification
r? types
relate `closure_substs.parent_substs()` to parent fn in NLL
Fixes#98589
The discrepancy between early- and late-bound lifetimes is because we map early-bound lifetimes into those found in the `closure_substs` while late-bound lifetimes are mapped into liberated free regions:
5f98537eb7/compiler/rustc_borrowck/src/universal_regions.rs (L255-L261)
r? `@rust-lang/types`
Add support for link-flavor rust-lld for iOS, tvOS and watchOS
This adds support for rust-lld for Apple *OS targets.
This was tested against targets ``aarch64-apple-ios`` and ``aarch64-apple-ios-sim`` with [a simple test program](https://github.com/Thog/rust-lld-apple-target_test).
It currently doesn't work with targets ``armv7-apple-ios`` and ``armv7s-apple-ios`` because of ``symbols.o`` not being generated with the correct CPU subtype. This will require changes in the ``object`` crate to expose an API.
As ``ld64.lld`` requires ``-platform_version`` with the minimal version supported and an sdk version, I made ``rustc_target::apple_base`` public to get access to ``*os_deployment_target`` helper functions and also added ``tvos_deployment_target`` as it was missing.
This adds support for rust-lld for Apple *OS targets.
This was tested against targets "aarch64-apple-ios" and "aarch64-apple-ios-sim".
For targets "armv7-apple-ios" and "armv7s-apple-ios", it doesn't link because of
"symbols.o" not being generated with the correct CPU subtype (changes in
the "object" crate needs to be done to support it).
Rollup of 6 pull requests
Successful merges:
- #99933 (parallelize HTML checking tool)
- #99958 (Improve position named arguments lint underline and formatting names)
- #100008 (Update all pre-cloned submodules on startup)
- #100049 (⬆️ rust-analyzer)
- #100070 (Clarify Cargo.toml comments)
- #100074 (rustc-docs: Be less specific about the representation of `+bundle`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
