Don't suggest replacing region with 'static in NLL
Fixes#73159
This is similar to #69350 - if the user didn't initially
write out a 'static lifetime, adding 'static in response to
a lifetime error is usually the wrong thing to do.
Fix ICE caused by non_exaustive_omitted_patterns struct lint
fixes#89382
Add check that a list of `Pat`s is non empty to prevent ICE in `FnCtxt::lint_non_exhaustive_omitted_patterns`.
Is related to #89374 and #89105
Fixed numerus of error message
When there are redundant trait requirements and these are hidden, a message is generated by the following code snippet:
`format!("{} redundant requirements hidden", count)`
But if there is only a single hidden requirement, it will still print this message in plural instead of singular.
Fix extra `non_snake_case` warning for shorthand field bindings
Fixes#89469. The problem is the innermost `if` condition here:
d14731cb3c/compiler/rustc_lint/src/nonstandard_style.rs (L435-L452)
This code runs for every `PatKind::Binding`, so if a struct has multiple fields, say A and B, and both are bound in a pattern using shorthands, the call to `self.check_snake_case()` will indeed be skipped in the `check_pat()` call for `A`; but when `check_pat()` is called for `B`, the loop will still iterate over `A`, and `field.ident (= A) != ident (= B)` will be true. I have fixed this by only looking at non-shorthand bindings, and only the binding that `check_pat()` was actually called for.
Fix bug with query modifier parsing
The previous macro_rules! parsers failed when an additional modifier was added
with ambiguity errors. The error is pretty unclear as to what exactly the cause
here is, but this change simplifies the argument parsing code such that the
error is avoided.
Extracted from other work, and somewhat duplicates 0358edeb5 from #85830, but
this approach seems a little simpler to me. Not technically currently necessary but seems
like a good cleanup.
Correctly handle supertraits for min_specialization
Supertraits of specialization markers could circumvent checks for
min_specialization. Elaborating predicates prevents this.
r? ````@nikomatsakis````
Stabilize `const_panic`
Closes#51999
FCP completed in #89006
```@rustbot``` label +A-const-eval +A-const-fn +T-lang
cc ```@oli-obk``` for review (not `r?`'ing as not on lang team)
Fix ICE with buffered lint referring to AST node deleted by everybody_loops
Fixes#87308. Note the following comment:
08759c691e/compiler/rustc_lint/src/early.rs (L415-L417)
As it turns out, this is not _always_ a bug, because `-Zunpretty=everybody_loops` causes a lot of AST nodes to be deleted, and thus some buffered lints will refer to non-existent node ids. To fix this, my changes simply ignore buffered lints if `-Zunpretty=everybody_loops` is enabled, which, from my understanding, shouldn't be a big issue because it only affects pretty-printing. Of course, a more elegant solution would only ignore buffered lints that actually point at deleted node ids, but I haven't figured out an easy way of achieving this.
For the concrete example in #87308, the buffered lint is created [here](08759c691e/compiler/rustc_expand/src/mbe/macro_rules.rs (L145-L151)) with the `lint_node_id` from [here](08759c691e/compiler/rustc_expand/src/mbe/macro_rules.rs (L319)), i.e. it points at the macro _expansion_, which then gets deleted by `ReplaceBodyWithLoop` [here](08759c691e/compiler/rustc_interface/src/passes.rs (L377)).
Consistently use 'supertrait'.
A subset of places referred to 'super-trait', so this changes them
to all use 'supertrait'. This matches 'supertype' and some other
usages. An exception is 'auto-trait' which is consistently used
in that manner.
Fix an ICE caused by type mismatch errors being ignored
This PR fixes#87771. It turns out that the check on `compiler/rustc_typeck/src/check/demand.rs:148` leads to the ICE. I removed it because the early return in [`check_expr_assign`](dec7fc3ced/compiler/rustc_typeck/src/check/expr.rs (L928)) already prevents unnecessary error messages from the call to `check_expr_coercable_to_type`.
[aarch64] add target feature outline-atomics
Enable outline-atomics by default as enabled in clang by the following commit
https://reviews.llvm.org/rGc5e7e649d537067dec7111f3de1430d0fc8a4d11
Performance improves by several orders of magnitude when using the LSE instructions
instead of the ARMv8.0 compatible load/store exclusive instructions.
Tested on Graviton2 aarch64-linux with
x.py build && x.py install && x.py test
When `cargo report future-incompatibilities` is stabilized
(see #71249), this will cause dependencies that trigger
this lint to be included in the report.
Remove some feature gates
The first commit removes various feature gates that are unused. The second commit replaces some `Fn` implementations with `Iterator` implementations, which is much cleaner IMO. The third commit replaces an unboxed_closures feature gate with min_specialization. For some reason the unboxed_closures feature gate suppresses the min_specialization feature gate from triggering on an `TrustedStep` impl. The last comment just turns a regular comment into a doc comment as drive by cleanup. I can move it to a separate PR if preferred.
Fixes#73159
This is similar to #69350 - if the user didn't initially
write out a 'static lifetime, adding 'static in response to
a lifetime error is usually the wrong thing to do.
Add expansion to while desugar spans
In the same vein as #88163, this reverts a change in Clippy behavior as a result of #80357 (and reverts some `#[allow]`s): This changes `clippy::blocks_in_if_conditions` to not fire on `while` loops. Though we might actually want Clippy to lint those cases, we should introduce the change purposefully, with tests, and possibly under a different lint name.
The actual change here is to add a desugaring expansion to the spans when lowering a `while` loop.
r? `@Manishearth`
These two functions are essentially no-ops (and compile to just a load and
return), but show up in process_obligations profiles with a high call count --
so worthwhile to try and inline them away.
Make diangostic item naming consistent
Right now there is about a 50/50 split of naming diagnostic items as `vec_type` vs `Vec`. So it is hard to guess a diagnostic item name with confidence. I know it's not great to change these retroactively, but I think it will be much easier to maintain consistency after consistency is established.
Make *const (), *mut () okay for FFI
Pointer-to-() is used occasionally in the standard library to mean "pointer to none-of-your-business". Examples:
- `RawWakerVTable::new` https://doc.rust-lang.org/1.51.0/std/task/struct.RawWakerVTable.html#method.new
- `<*const T>::to_raw_parts` https://doc.rust-lang.org/nightly/std/primitive.pointer.html#method.to_raw_parts
I believe it's useful for the same purpose in FFI signatures, even while `()` itself is not FFI safe. The following should be allowed:
```rust
extern "C" {
fn demo(pc: *const (), pm: *mut ());
}
```
Prior to this PR, those pointers were not considered okay for an extern signature.
```console
warning: `extern` block uses type `()`, which is not FFI-safe
--> src/main.rs:2:17
|
2 | fn demo(pc: *const (), pm: *mut ());
| ^^^^^^^^^ not FFI-safe
|
= note: `#[warn(improper_ctypes)]` on by default
= help: consider using a struct instead
= note: tuples have unspecified layout
warning: `extern` block uses type `()`, which is not FFI-safe
--> src/main.rs:2:32
|
2 | fn demo(pc: *const (), pm: *mut ());
| ^^^^^^^ not FFI-safe
|
= help: consider using a struct instead
= note: tuples have unspecified layout
```
Deriving: Include bound generic params in type parameters for where clause
Fixes#89188.
The `derive` macro ignored the `for<'s>` needed with the `Fn` trait in that code example.
edit: I'm unsure if this might cause regressions. I'm not an experienced compiler developer so I'm not used to thinking about unwanted side effects code changes like this might have.
For some reason unboxed_closures supresses the feature gate for
min_specialization when implementing TrustedStep. min_specialization is
the true feature that is used.
The previous macro_rules! parsers failed when an additional modifier was added
with ambiguity errors. The error is pretty unclear as to what exactly the cause
here is, but this change simplifies the argument parsing code such that the
error is avoided.
resolve: Cache module loading for all foreign modules
It was previously cached for modules loaded from `fn get_module`, but not for modules loaded from `fn build_reduced_graph_for_external_crate_res`.
This also makes all foreign modules use their real parent, span and expansion instead of possibly a parent/span/expansion of their reexport.
Modules are also often compared using referential equality (`ptr::eq`), this change makes such comparisons correct in all cases.
An ICE happening on attempt to decode expansions for foreign enums and traits is avoided.
Also local enums and traits are now added to the module map.
Follow up to https://github.com/rust-lang/rust/pull/88872.
r? `@cjgillot`
It was previously cached for modules loaded from `fn get_module`, but not for modules loaded from `fn build_reduced_graph_for_external_crate_res`.
This also makes all foreign modules use their real parent, span and expansion instead of possibly a parent/span/expansion of their reexport.
An ICE happening on attempt to decode expansions for foreign enums and traits is avoided.
Also local enums and traits are now added to the module map.
Avoid nondeterminism in trimmed_def_paths
Previously this query depended on the global interning order of Symbols, which
meant that irrelevant changes could influence the query and cause
recompilations. This commit ensures that the return set is stable and will not
be affected by the global order by deterministically (in lexicographic order)
choosing a name to use if there are multiple names for a single DefId.
This should fix the cause of the [regressions] in #83343.
[regressions]: https://perf.rust-lang.org/compare.html?start=9620f3a84b079decfdc2e557be007580b097fe43&end=addb4da686a97da46159f0123cb6cdc2ce3d7fdb
Fix clippy lints
I'm currently working on allowing clippy to run on librustdoc after a discussion I had with `@Mark-Simulacrum.` So in the meantime, I fixed a few lints on the compiler crates.
The checks removed here caused a small perf regression:
https://github.com/rust-lang/rust/pull/88824#issuecomment-932664761
Since the attribute is currently only applied to traits, I don't think
it's worth keeping the additional checks for now.
If/when we decide to apply the attribute somewhere else, we can
(partially) revert this and evaluate if the perf impact is acceptable.
A subset of places referred to 'super-trait', so this changes them
to all use 'supertrait'. This matches 'supertype' and some other
usages. An exception is 'auto-trait' which is consistently used
in that manner.
Rollup of 7 pull requests
Successful merges:
- #85223 (rustdoc: Clarified the attribute which prompts the warning)
- #88847 (platform-support.md: correct ARMv7+MUSL platform triple notes)
- #88963 (Coerce const FnDefs to implement const Fn traits )
- #89376 (Fix use after drop in self-profile with llvm events)
- #89422 (Replace whitespaces in doctests' name with dashes)
- #89440 (Clarify a sentence in the documentation of Vec (#84488))
- #89441 (Normalize after substituting via `field.ty()`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Normalize after substituting via `field.ty()`
Back in https://github.com/rust-lang/rust/issues/72476 I hadn't understood where the problem was coming from, and only worked around the issue. What happens is that calling `field.ty()` on a field of a generic struct substitutes the appropriate generics but doesn't normalize the resulting type.
As a consumer of types I'm surprised that one would substitute without normalizing, feels like a footgun, so I added a comment.
Fixes https://github.com/rust-lang/rust/issues/89393.
Fix use after drop in self-profile with llvm events
self-profile with `-Z self-profile-events=llvm` have failed with a segmentation fault due to this use after drop.
this type of events can be more useful now that the new passmanager is the default.
Coerce const FnDefs to implement const Fn traits
You can now pass a FnDef to a function expecting `F` where `F: ~const FnTrait`.
r? ``@oli-obk``
``@rustbot`` label T-compiler F-const_trait_impl
Rework HIR API to make invocations of the hir_crate query harder.
`hir_crate` forces the recomputation of queries that depend on it.
This PR aims at avoiding useless invocations of `hir_crate` by making dependent code go through `tcx.hir()`.
Correct caller/callsite confusion in inliner message
`callee_body` is the MIR `Body` for the `callsite.callee` so this message basically says `"Inline {bar span} into bar"` when it should say `"Inline bar into foo"`.
Extracted out of #82280
Improve error message for `printf`-style format strings
Fixes#89173. The following is actually supported today:
```rust
fn main() {
let num = 5;
let width = 20;
print!("%*2$x", num, width);
}
```
```
error: multiple unused formatting arguments
--> src/main.rs:4:21
|
4 | print!("%*2$x", num, width);
| ------- ^^^ ^^^^^ argument never used
| || |
| || argument never used
| |help: format specifiers use curly braces: `{:1$x}`
| multiple missing formatting specifiers
|
= note: printf formatting not supported; see the documentation for `std::fmt`
```
However, as noted in #89173, something like
```rust
print!("%0*x", width, num);
```
does not give a helpful suggestion. I think this is partly intended, because there actually _is_ no Rust equivalent to this; you always have to use a positional or named argument to specify the width (instead of just using the "next" argument, as `printf` or even `.*` as a precision specifier in Rust would). Therefore, I have added a note:
```
[...]
note: format specifiers use curly braces, and you have to use a positional or named parameter for the width
--> t2.rs:4:13
|
4 | print!("%0*x", width, num);
| ^^^^
= note: printf formatting not supported; see the documentation for `std::fmt`
```
This is not perfect, but it should at least point the user in the right direction, instead of issuing no explanation at all.
cc ```@lcnr```
Added -Z randomize-layout flag
An implementation of #77316, it currently randomly shuffles the fields of `repr(rust)` types based on their `DefPathHash`
r? ``@eddyb``
Rollup of 7 pull requests
Successful merges:
- #88838 (Do not suggest importing inaccessible items)
- #89251 (Detect when negative literal indices are used and suggest appropriate code)
- #89321 (Rebase resume argument projections during state transform)
- #89327 (Pick one possible lifetime in case there are multiple choices)
- #89344 (Cleanup lower_generics_mut and make span be the bound itself)
- #89397 (Update `llvm` submodule to fix function name mangling on x86 Windows)
- #89412 (Add regression test for issues #88969 and #89119 )
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Cleanup lower_generics_mut and make span be the bound itself
Closes#86298 (supersedes those changes)
r? `@cjgillot` since you reviewed the other PR
(Used wrong branch for #89338)
Pick one possible lifetime in case there are multiple choices
In case a lifetime variable is created, but doesn't have an obvious lifetime in the list of named lifetimes that it should be inferred to, just pick the first one for the diagnostic.
This happens e.g. in
```rust
fn foo<'a, 'b>(a: Struct<'a>, b: Struct<'b>) -> impl Trait<'a, 'b> {
if bar() { a } else { b }
}
```
where we get a lifetime variable that combines the lifetimes of `a` and `b` creating a lifetime that is the intersection of both. Right now the type system cannot express this and thus we get an error, but that error also can't express this.
I can also create an entirely new diagnostic that mentions all involved lifetimes, so it would actually mention `'a` and `'b` instead of just `'b`.
Rebase resume argument projections during state transform
When remapping a resume argument with projections rebase them on top of
the new base.
The case where resume argument has projections is unusual, but might
arise with box syntax where the assignment is performed directly into
the box without an intermediate temporary.
Fixes#85635.
Do not suggest importing inaccessible items
Fixes#88472. For this example:
```rust
mod a {
struct Foo;
}
mod b {
type Bar = Foo;
}
```
rustc currently emits:
```
error[E0412]: cannot find type `Foo` in this scope
--> test.rs:6:16
|
6 | type Bar = Foo;
| ^^^ not found in this scope
|
help: consider importing this struct
|
6 | use a::Foo;
|
```
this is incorrect, as applying this suggestion leads to
```
error[E0603]: struct `Foo` is private
--> test.rs:6:12
|
6 | use a::Foo;
| ^^^ private struct
|
note: the struct `Foo` is defined here
--> test.rs:2:5
|
2 | struct Foo;
| ^^^^^^^^^^^
```
With my changes, I get:
```
error[E0412]: cannot find type `Foo` in this scope
--> test.rs:6:16
|
6 | type Bar = Foo;
| ^^^ not found in this scope
|
= note: this struct exists but is inaccessible:
a::Foo
```
As for the wildcard mentioned in #88472, I would argue that the warning is actually correct, since the import _is_ unused. I think the real issue is the wrong suggestion, which I have fixed here.
CTFE: tweak aggregate rvalue handling
I have not looked at this code in ages... I think Miri does not even hit it, since (most?) aggregate rvalues are lowered somewhere in the MIR pipeline, but CTFE does hit it.
So this adds some extra sanity assertions, and removes a ZST special case -- ZST should only be special cased fairly late (when the actual memory access happens); e.g. `!` is a ZST and we still want `copy_op` to be called for it since it will perform validation (and raise UB, since `!` is never valid).
fix(lint): don't suggest refutable patterns to "fix" irrefutable bind
In function arguments and let bindings, do not suggest changing `C` to `Foo::C` unless `C` is the only variant of `Foo`, because it won't work.
The general warning is still kept, because code like this is confusing.
Fixes#88730
p.s. `src/test/ui/lint/lint-uppercase-variables.rs` already tests the one-variant case.
Suggest similarly named associated items in trait impls
Fix#85942
Previously, the compiler didn't suggest similarly named associated items unlike we do in many situations. This patch adds such diagnostics for associated functions, types, and constants.
Fix ICE when `start` lang item has wrong generics
In my previous pr #87875 I missed the requirements on the `start` lang item due to its relative difficulty to test and opting for more conservative estimates. This fixes that by updating the requirement to be exactly one generic type.
The `start` lang item should have exactly one generic type for the return type of the `main` fn ptr passed to it. I believe having zero would previously *sometimes* compile (often with the use of `fn() -> ()` as the fn ptr but it was likely UB to call if the return type of `main` was not `()` as far as I know) however it also sometimes would not for various errors including ICEs and LLVM errors depending on exact situations. Having more than 1 generic has always failed with an ICE because only the one generic type is expected and provided.
Fixes#79559, fixes#73584, fixes#83117 (all duplicates)
Relevant to #9307
r? ````@cjgillot````
Move encode_metadata out of CrateStore.
`rustc_metadata` is already accessible by all client crates. It does not need to be called trough a trait object.
Enable outline-atomics by default as enabled in clang by the following commit
https://reviews.llvm.org/rGc5e7e649d537067dec7111f3de1430d0fc8a4d11
Performance improves by several orders of magnitude when using the LSE instructions
instead of the ARMv8.0 compatible load/store exclusive instructions.
Tested on Graviton2 aarch64-linux with
x.py build && x.py install && x.py test
2229: Consume IfLet expr
When using the IfLet guard feature, we can ICE when attempting to resolve PlaceBuilders.
For pattern matching, we currently don't consume the IfLet expression when "visiting" the arms leading us to not "read" all variables and hence not being able to resolve them.
r? `@nikomatsakis`
Closes https://github.com/rust-lang/rust/issues/88118
Previously this query depended on the global interning order of Symbols, which
meant that irrelevant changes could influence the query and cause
recompilations. This commit ensures that the return set is stable and will not
be affected by the global order by deterministically (in lexicographic order)
choosing a name to use if there are multiple names for a single DefId.
Avoid spurious "previous iteration of loop" errors
Only follow backwards edges during `get_moved_indexes` if the move path is definitely initialized at loop entry. Otherwise, the error occurred prior to the loop, so we ignore the backwards edges to avoid generating misleading "value moved here, in previous iteration of loop" errors.
This patch also slightly improves the analysis of inits, including `NonPanicPathOnly` initializations (which are ignored by `drop_flag_effects::for_location_inits`). This is required for the definite initialization analysis, but may also help find certain skipped reinits in rare cases.
Patch passes all non-ignored src/test/ui testcases.
Fixes#72649.
Don't anonymize bound region names during typeck
Once this anonymization has performed, we have no
way of recovering the original names during NLL
borrow checking. Keeping the original names allows
error messages in full NLL mode to contain the original
bound region names.
As a result, the typeck results may contain types that
differ only in the names used for their bound regions. However,
anonimization of bound regions does not guarantee that
all distinct types are unqual (e.g. not subtypes of each other).
For example, `for<'a> fn(&'a u32, &'a u32)` and
`for<'b, 'c> fn(&'b u32, &'c u32)` are subtypes of each other,
as explained here:
63cc2bb3d0/compiler/rustc_infer/src/infer/nll_relate/mod.rs (L682-L690)
Therefore, any code handling types with higher-ranked regions already
needs to handle the case where two distinct `Ty`s are 'actually'
equal.
PassWrapper: handle function rename from upstream D36850
thinLTOResolvePrevailingInModule became thinLTOFinalizeInModule and
gained the ability to propagate noRecurse and noUnwind function
attributes. I ran codegen tests with it both on and off, as the upstream
patch uses it in both modes, and the tests pass both ways. Given that,
it seemed reasonable to go ahead and let the propagation be enabled in
rustc, and see what happens. See https://reviews.llvm.org/D36850 for
more examples of how the new version of the function gets used.
r? ``@nikic`` cc ``@nagisa``
Improve help for recursion limit errors
- Tweak help message and suggested limit (handle `0` case).
- Add test for #75602 (it was already fixed, maybe can be resolved too).
Fixes#76424
Use larger span for adjustment THIR expressions
Currently, we use a relatively 'small' span for THIR
expressions generated by an 'adjustment' (e.g. an autoderef,
autoborrow, unsizing). As a result, if a borrow generated
by an adustment ends up causing a borrowcheck error, for example:
```rust
let mut my_var = String::new();
let my_ref = &my_var
my_var.push('a');
my_ref;
```
then the span for the mutable borrow may end up referring
to only the base expression (e.g. `my_var`), rather than
the method call which triggered the mutable borrow
(e.g. `my_var.push('a')`)
Due to a quirk of the MIR borrowck implementation,
this doesn't always get exposed in migration mode,
but it does in many cases.
This commit makes THIR building consistently use 'larger'
spans for adjustment expressions. These spans are recoded
when we first create the adjustment during typecheck. For
example, an autoref adjustment triggered by a method call
will record the span of the entire method call.
The intent of this change it make it clearer to users
when it's the specific way in which a variable is
used (for example, in a method call) that produdes
a borrowcheck error. For example, an error message
claiming that a 'mutable borrow occurs here' might
be confusing if it just points at a usage of a variable
(e.g. `my_var`), when no `&mut` is in sight. Pointing
at the entire expression should help to emphasize
that the method call itself is responsible for
the mutable borrow.
In several cases, this makes the `#![feature(nll)]` diagnostic
output match up exactly with the default (migration mode) output.
As a result, several `.nll.stderr` files end up getting removed
entirely.
In function arguments and let bindings, do not suggest changing `C` to `Foo::C`
unless `C` is the only variant of `Foo`, because it won't work.
The general warning is still kept, because code like this is confusing.
Fixes#88730
Rollup of 8 pull requests
Successful merges:
- #87260 (Libgccjit codegen)
- #89212 (x.py: run `rustup toolchain link` in setup)
- #89233 (Hide `<...> defined here` note if the source is not available)
- #89235 (make junit output more consistent with default format)
- #89255 (Fix incorrect disambiguation suggestion for associated items)
- #89276 (Fix the population of the `union.impls` field)
- #89283 (Add regression test for issue #83564)
- #89318 (rustc_session: Remove lint store from `Session`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Add an intermediate representation to exhaustiveness checking
The exhaustiveness checking algorithm keeps deconstructing patterns into a `Constructor` and some `Fields`, but does so a bit all over the place. This PR introduces a new representation for patterns that already has that information, so we only compute it once at the start.
I find this makes code easier to follow. In particular `DeconstructedPat::specialize` is a lot simpler than what happened before, and more closely matches the description of the algorithm. I'm also hoping this could help for the project of librarifying exhaustiveness for rust_analyzer since it decouples the algorithm from `rustc_middle::Pat`.
As shown in the two test requirements that got updated, if there's other problems,
then those other problems are probably the root cause of the incorrect generics count.
Fix incorrect disambiguation suggestion for associated items
Fixes#88806. I have not added a new test case, because the erroneous behavior is already present in existing test cases.
Libgccjit codegen
This PR introduces a subtree for a gcc-based codegen backend to the repository, per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI, but we do verify that the backend checks (i.e., `cargo check`) successfully.
Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc, with semi-regular upstreaming, like with other subtrees.
Previously, the compiler didn't suggest similarly named associated items
unlike we do in many situations. This patch adds such diagnostics for
associated functions, types and constants.
When remapping a resume argument with projections rebase them on top of
the new base.
The case where resume argument has projections is unusual, but might
arise with box syntax where the assignment is performed directly into
the box without an intermediate temporary.
Add SOLID targets
This PR introduces new tier 3 targets for [SOLID](https://www.kmckk.co.jp/eng/SOLID/) embedded development platform by Kyoto Microcomputer Co., Ltd.
| Target name | `target_arch` | `target_vendor` | `target_os` |
|--------------------------------|---------------|-----------------|--------------|
| `aarch64-kmc-solid_asp3` | `aarch64` | `kmc` | `solid_asp3` |
| `armv7a-kmc-solid_asp3-eabi` | `arm` | `kmc` | `solid_asp3` |
| `armv7a-kmc-solid_asp3-eabihf` | `arm` | `kmc` | `solid_asp3` |
## Related PRs
- [ ] `libc`: https://github.com/rust-lang/libc/pull/2227
- [ ] `cc`: https://github.com/alexcrichton/cc-rs/pull/609
## Non-blocking Issues
- [ ] The target kernel can support `Thread::unpark` directly, but this property is not utilized because the underlying kernel feature is used to implement `Condvar` and it's unclear whether `std` should guarantee that parking tokens are not clobbered by other synchronization primitives.
- [ ] The rustc book: The page title "\*-kmc-solid-\*" shows up as "-kmc-solid-" in TOC
## Tier 3 Target Policy
As tier 3 targets, the new targets are required to adhere to [the tier 3 target policy](https://doc.rust-lang.org/nightly/rustc/target-tier-policy.html#tier-3-target-policy) requirements. This section quotes each requirement in entirety and describes how they are met.
> - 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.)
See [`src/doc/rustc/src/platform-support/kmc-solid.md`](https://github.com/kawadakk/rust/blob/release-add-solid-support/src/doc/rustc/src/platform-support/kmc-solid.md).
> - 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.
The new target names follow this format: `$ARCH-$VENDOR-$OS-$ABI`, which is already adopted by most existing targets. `$ARCH` and `$ABI` follow the convention: `aarch64-*` for AArch64, `armv7a-*-eabi` for Armv7-A with EABI. `$OS` is used to distinguish multiple variations of the platform in a somewhat similar way to the Apple targets, though we are only adding one variation in this PR. `$VENDOR` denotes the platform vendor name similarly to the Apple, Solaris, SGX, and VxWorks targets.
`$OS` corresponds to the value of `target_os` and takes the format `solid-$KERNEL`. The inclusion of a hyphen prevents unique decomposition of target names, though the mapping between target names and target attributes isn't trivial in the first place, e.g., because of the Android targets.
More targets may be added later, as we support other base kernels (there are at least three at the point of writing) and are interested in supporting other processor architectures in the future.
> - 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.
> - If the target supports building host tools (such as `rustc` or `cargo`), those host tools must not depend on proprietary (non-FOSS) libraries, other than ordinary runtime libraries supplied by the platform and commonly used by other binaries built for the target. 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.
> - Targets should not require proprietary (non-FOSS) components to link a functional binary or library.
> - "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.
We intend to make the contribution fully available under the standard Rust license with no additional legal restrictions whatsoever. This PR does not introduce any new dependency less permissive than the Rust license policy, and we are willing to ensure this doesn't happen for future contributions regarding the new targets.
The new targets don't support building host tools.
Although the new targets use a platform-provided C compiler toolchain, it can be substituted by [GNU Arm Embedded Toolchain](https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm) for testing purposes.
> - 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.
Most features are implemented. The following features are not implemented due to the lack of native support:
- `fs::File::{file_attr, truncate, duplicate, set_permissions}`
- `fs::{symlink, link, canonicalize}`
- Process creation
- Command-line arguments
~~Networking is not implemented yet, and we intend to add it as soon as it's ready.~~
Edit (2021-07-07): Networking is now implemented.
Backtrace generation is not really a good fit for embedded targets, so it's intentionally left unimplemented. Unwinding is functional, however.
> - 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 tests (even if they do not pass), the documentation must explain how to run tests for the target, using emulation if possible or dedicated hardware if necessary.
See [`src/doc/rustc/src/platform-support/kmc-solid.md`](https://github.com/kawadakk/rust/blob/release-add-solid-support/src/doc/rustc/src/platform-support/kmc-solid.md). Running tests is not supported.
> - 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.
> - 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.
> - 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.
We acknowledge these requirements and intend to ensure they are met.
There are no closely related targets at the moment.
Suggest using the path separator for tuple struct
Fix confusing error message `constructor is not visible here due to private fields` for tuple struct
closes#83450
SOLID[1] is an embedded development platform provided by Kyoto
Microcomputer Co., Ltd. This commit introduces a basic Tier 3 support
for SOLID.
# New Targets
The following targets are added:
- `aarch64-kmc-solid_asp3`
- `armv7a-kmc-solid_asp3-eabi`
- `armv7a-kmc-solid_asp3-eabihf`
SOLID's target software system can be divided into two parts: an
RTOS kernel, which is responsible for threading and synchronization,
and Core Services, which provides filesystems, networking, and other
things. The RTOS kernel is a μITRON4.0[2][3]-derived kernel based on
the open-source TOPPERS RTOS kernels[4]. For uniprocessor systems
(more precisely, systems where only one processor core is allocated for
SOLID), this will be the TOPPERS/ASP3 kernel. As μITRON is
traditionally only specified at the source-code level, the ABI is
unique to each implementation, which is why `asp3` is included in the
target names.
More targets could be added later, as we support other base kernels
(there are at least three at the point of writing) and are interested
in supporting other processor architectures in the future.
# C Compiler
Although SOLID provides its own supported C/C++ build toolchain, GNU Arm
Embedded Toolchain seems to work for the purpose of building Rust.
# Unresolved Questions
A μITRON4 kernel can support `Thread::unpark` natively, but it's not
used by this commit's implementation because the underlying kernel
feature is also used to implement `Condvar`, and it's unclear whether
`std` should guarantee that parking tokens are not clobbered by other
synchronization primitives.
# Unsupported or Unimplemented Features
Most features are implemented. The following features are not
implemented due to the lack of native support:
- `fs::File::{file_attr, truncate, duplicate, set_permissions}`
- `fs::{symlink, link, canonicalize}`
- Process creation
- Command-line arguments
Backtrace generation is not really a good fit for embedded targets, so
it's intentionally left unimplemented. Unwinding is functional, however.
## Dynamic Linking
Dynamic linking is not supported. The target platform supports dynamic
linking, but enabling this in Rust causes several problems.
- The linker invocation used to build the shared object of `std` is
too long for the platform-provided linker to handle.
- A linker script with specific requirements is required for the
compiled shared object to be actually loadable.
As such, we decided to disable dynamic linking for now. Regardless, the
users can try to create shared objects by manually invoking the linker.
## Executable
Building an executable is not supported as the notion of "executable
files" isn't well-defined for these targets.
[1] https://solid.kmckk.com/SOLID/
[2] http://ertl.jp/ITRON/SPEC/mitron4-e.html
[3] https://en.wikipedia.org/wiki/ITRON_project
[4] https://toppers.jp/
thinLTOResolvePrevailingInModule became thinLTOFinalizeInModule and
gained the ability to propagate noRecurse and noUnwind function
attributes. I ran codegen tests with it both on and off, as the upstream
patch uses it in both modes, and the tests pass both ways. Given that,
it seemed reasonable to go ahead and let the propagation be enabled in
rustc, and see what happens. See https://reviews.llvm.org/D36850 for
more examples of how the new version of the function gets used.
Improve cause information for NLL higher-ranked errors
This PR has several interconnected pieces:
1. In some of the NLL region error code, we now pass
around an `ObligationCause`, instead of just a plain `Span`.
This gets forwarded into `fulfill_cx.register_predicate_obligation`
during error reporting.
2. The general InferCtxt error reporting code is extended to
handle `ObligationCauseCode::BindingObligation`
3. A new enum variant `ConstraintCategory::Predicate` is added.
We try to avoid using this as the 'best blame constraint' - instead,
we use it to enhance the `ObligationCause` of the `BlameConstraint`
that we do end up choosing.
As a result, several NLL error messages now contain the same
"the lifetime requirement is introduced here" message as non-NLL
errors.
Having an `ObligationCause` available will likely prove useful
for future improvements to NLL error messages.
Pass real crate-level attributes to `pre_expansion_lint`
The PR concerns the unstable feature `register_tool` (#66079).
The feature's implementation requires the attributes of the crate being compiled, so that when attributes like `allow(foo::bar)` are encountered, it can be verified that `register_tool(foo)` appears in the crate root.
However, the crate's attributes are not readily available during early lint passes. Specifically, on this line, `krate.attrs` appears to be the attributes of the current source file, not the attributes of the whole crate: bf642323d6/compiler/rustc_lint/src/context.rs (L815)
Consequently, "unknown tool" errors were being produced when `allow(foo::bar)` appeared in a submodule, even though `register_tool(foo)` appeared in the crate root.
EDITED: The proposed fix is to obtain the real crate-level attributes in `configure_and_expand` and pass them to `pre_expansion_lint`. (See `@petrochenkov's` [comment](https://github.com/rust-lang/rust/pull/89214#issuecomment-926927072) below.)
The original "prosed fix" text follows.
---
The proposed fix is to add an `error_on_unknown_tool` flag to `LintLevelsBuilder`. The flag controls whether "unknown tool" errors are emitted. The flag is set during late passes, but not earlier.
More specifically, this PR contains two commits:
* The first adds a `known-tool-in-submodule` UI test that does not currently pass.
* The second adds the `error_on_unknown_tool` flag. The new test passes with the addition of this flag.
This change has the added benefit of eliminating some errors that were duplicated in existing tests.
To the reviewer: please check that I implemented the UI test correctly.
This PR has several interconnected pieces:
1. In some of the NLL region error code, we now pass
around an `ObligationCause`, instead of just a plain `Span`.
This gets forwarded into `fulfill_cx.register_predicate_obligation`
during error reporting.
2. The general InferCtxt error reporting code is extended to
handle `ObligationCauseCode::BindingObligation`
3. A new enum variant `ConstraintCategory::Predicate` is added.
We try to avoid using this as the 'best blame constraint' - instead,
we use it to enhance the `ObligationCause` of the `BlameConstraint`
that we do end up choosing.
As a result, several NLL error messages now contain the same
"the lifetime requirement is introduced here" message as non-NLL
errors.
Having an `ObligationCause` available will likely prove useful
for future improvements to NLL error messages.
Don't normalize opaque types with escaping late-bound regions
Fixes#88862
Turns out, this has some really bad perf implications in large types (issue #88862). While we technically can handle them fine, it doesn't change test output either way. For now, revert with an added benchmark. Future attempts to change this back will have to consider perf.
Needs a perf run once https://github.com/rust-lang/rustc-perf/pull/1033 is merged
r? `@nikomatsakis`
Turns out, this has some really bad perf implications in large types (issue #88862). While we technically can handle them fine, it doesn't change test output either way. For now, revert with an added benchmark. Future attempts to change this back will have to consider perf.
Validate builtin attributes for macro args.
This adds some validation for `path`, `crate_type`, and `recursion_limit` attributes so that they will now return an error if you attempt to pass a macro into them (such as `#[path = foo!()]`). Previously, the attribute would be completely ignored. These attributes are special because their values need to be known before/during expansion.
cc #87681
Now `Fields` is just a `Vec` of patterns, with some extra info on the
side to reconstruct patterns when needed. This emphasizes that this
extra info is not central to the algorithm.
Once this anonymization has performed, we have no
way of recovering the original names during NLL
borrow checking. Keeping the original names allows
error messages in full NLL mode to contain the original
bound region names.
As a result, the typeck results may contain types that
differ only in the names used for their bound regions. However,
anonimization of bound regions does not guarantee that
all distinct types are unqual (e.g. not subtypes of each other).
For example, `for<'a> fn(&'a u32, &'a u32)` and
`for<'b, 'c> fn(&'b u32, &'c u32)` are subtypes of each other,
as explained here:
63cc2bb3d0/compiler/rustc_infer/src/infer/nll_relate/mod.rs (L682-L690)
Therefore, any code handling types with higher-ranked regions already
needs to handle the case where two distinct `Ty`s are 'actually'
equal.
