I attempted to do this in a manner that preserved the line numbers to reduce the
review effort on the resulting diff, but we still have to deal with the
ramifications of how a future-incompat lint behaves compared to a hard-error (in
terms of its impact on the diagnostic output).
(cherry picked from commit 1c3424bfc1)
`os_local` impl of `thread_local` — regardless of whether it is const and
unlike other implementations — includes an `fn __init(): EXPR`.
Existing implementation of the lint checked for the presence of said
function and whether the expr can be made const. Because for `os_local`
we always have an `__init()`, it triggers for const implementations.
The solution is to check whether the `__init()` function is already const.
If it is `const`, there is nothing to do. Otherwise, we verify that we can
make it const.
Co-authored-by: Alejandra González <blyxyas@gmail.com>
Allowing the Xcode version to "float" based on whatever default GitHub
selects creates an unreliable environment. When GitHub changes the
default, we can have multiple jobs in the same run using different
versions as it rolls out across machines. It can also cause oscillation
between runs as different machines are used. It also causes
unpredictable timing when the updates happen.
This change helps ensure that the version that is used is pinned. The
downside is that it requires manually bumping the version, and the risk
that if we take too long, older Xcodes will be removed and that will
break the build.
(cherry picked from commit 4ce1f1cffc)
This seems to fix two sporadic errors that have been appearing in CI.
One is an issue with cmake being unable to verify that cmake is able to
build a simple test program. The other is a `invalid r_symbolnum`
linking error when trying to build one of cranelift's tests.
This is intended as a temporary fix until we can figure out how to
resolve those issues.
(cherry picked from commit 4fd3cf96a1)
Update the library paths to correctly refer to libdemo{1,2}_hexagon
and switch to the release build instead.
Update references to libstandalone to the specific G0/PIC archive instead.
(cherry picked from commit 647a453657)
[Beta 1.77] Fix bootstrapping from 1.76
Due to the timing of the revert for stabilization of c_str_literal (https://github.com/rust-lang/rust/pull/119528 which reverted in 1.76) and trait_upcasting (https://github.com/rust-lang/rust/pull/120269 which reverted in 1.76), which happened after https://github.com/rust-lang/rust/pull/119211 (Bump stage0 to 1.76 beta), this resulted in some of the feature attributes not being restored which are needed to be able to bootstrap from 1.76. This restores those features.
This also includes a stage0 bump to the just released stable. This is necessary because stage0 was currently pointing at an old beta which did not contain the reverts.
Fixes#120810
rustdoc: Correctly handle attribute merge if this is a glob reexport
Fixes#120487.
The regression was introduced in https://github.com/rust-lang/rust/pull/113091. Only non-glob reexports should have been impacted.
cc `````@Nemo157`````
r? `````@notriddle`````
Don't hash lints differently to non-lints.
`Diagnostic::keys`, which is used for hashing and equating diagnostics, has a surprising behaviour: it ignores children, but only for lints. This was added in #88493 to fix some duplicated diagnostics, but it doesn't seem necessary any more.
This commit removes the special case and only four tests have changed output, with additional errors. And those additional errors aren't exact duplicates, they're just similar. For example, in src/tools/clippy/tests/ui/same_name_method.rs we currently have this error:
```
error: method's name is the same as an existing method in a trait
--> $DIR/same_name_method.rs:75:13
|
LL | fn foo() {}
| ^^^^^^^^^^^
|
note: existing `foo` defined here
--> $DIR/same_name_method.rs:79:9
|
LL | impl T1 for S {}
| ^^^^^^^^^^^^^^^^
```
and with this change we also get this error:
```
error: method's name is the same as an existing method in a trait
--> $DIR/same_name_method.rs:75:13
|
LL | fn foo() {}
| ^^^^^^^^^^^
|
note: existing `foo` defined here
--> $DIR/same_name_method.rs:81:9
|
LL | impl T2 for S {}
|
```
I think printing this second argument is reasonable, possibly even preferable to hiding it. And the other cases are similar.
r? `@estebank`
Provide more context on derived obligation error primary label
Expand the primary span of E0277 when the immediate unmet bound is not what the user wrote:
```
error[E0277]: the trait bound `i32: Bar` is not satisfied
--> f100.rs:6:6
|
6 | <i32 as Foo>::foo();
| ^^^ the trait `Bar` is not implemented for `i32`, which is required by `i32: Foo`
|
help: this trait has no implementations, consider adding one
--> f100.rs:2:1
|
2 | trait Bar {}
| ^^^^^^^^^
note: required for `i32` to implement `Foo`
--> f100.rs:3:14
|
3 | impl<T: Bar> Foo for T {}
| --- ^^^ ^
| |
| unsatisfied trait bound introduced here
```
Fix#40120.
std: thread_local::register_dtor fix proposal for FreeBSD.
following-up 5d3d347 commit, rust started to spin
__cxa_thread_call_dtors warnings even without any TLS usage. using instead home made TLS destructor handler `register_dtor_fallback`.
close#120413
document `FromIterator for Vec` allocation behaviors
[t-libs discussion](https://rust-lang.zulipchat.com/#narrow/stream/259402-t-libs.2Fmeetings/topic/Meeting.202024-01-24/near/417686526) about #120091 didn't reach a strong consensus, but it was agreed that if we keep the current behavior it should at least be documented even though it is an implementation detail.
The language is intentionally non-committal. The previous (non-existent) documentation permits a lot of implementation leeway and we want retain that. In some cases we even must retain it to be able to rip out some code paths that rely on unstable features.
bors