fix(resolve): update the ambiguity glob binding as warning recursively
Fixes#47525Fixes#56593, but `issue-56593-2.rs` is not fixed to ensure backward compatibility.
Fixes#98467Fixes#105235Fixes#112713
This PR had added a field called `warn_ambiguous` in `NameBinding` which is only for back compatibly reason and used for lint.
More details: https://github.com/rust-lang/rust/pull/112743
r? `@petrochenkov`
Rollup of 7 pull requests
Successful merges:
- #113773 (Don't attempt to compute layout of type referencing error)
- #114107 (Prevent people from assigning me as a PR reviewer)
- #114124 (tests/ui/proc-macro/*: Migrate FIXMEs to check-pass)
- #114171 (Fix switch-stdout test for none unix/windows platforms)
- #114172 (Fix issue_15149 test for the SGX target)
- #114173 (btree/map.rs: remove "Basic usage" text)
- #114174 (doc: replace wrong punctuation mark)
r? `@ghost`
`@rustbot` modify labels: rollup
Fix issue_15149 test for the SGX target
PR https://github.com/rust-lang/rust/pull/112390 moved tests to std. Unfortunately, this caused the `issue_15149` test to be enabled for the SGX target. This is incorrect as the SGX target does not support the `env::current_exe()` call.
Fix switch-stdout test for none unix/windows platforms
PR #112390 moved tests to std. Unfortunately, there is a typo which causes issues on platforms other than unix and windows.
tests/ui/proc-macro/*: Migrate FIXMEs to check-pass
proc-macros are processed early in the compiler pipeline. There is no need to involve codegen. So change to check-pass.
I have also looked through each changed test and to me it is sufficiently clear that codegen is not needed for the purpose of the test.
I skipped changing `tests/ui/proc-macro/no-missing-docs.rs` in this commit because it was not clear to me that it can be changed to check-pass.
Part of #62277
Rollup of 7 pull requests
Successful merges:
- #114099 (privacy: no nominal visibility for assoc fns )
- #114128 (When flushing delayed span bugs, write to the ICE dump file even if it doesn't exist)
- #114138 (Adjust spans correctly for fn -> method suggestion)
- #114146 (Skip reporting item name when checking RPITIT GAT's associated type bounds hold)
- #114147 (Insert RPITITs that were shadowed by missing ADTs that resolve to [type error])
- #114155 (Replace a lazy `RefCell<Option<T>>` with `OnceCell<T>`)
- #114164 (Add regression test for `--cap-lints allow` and trait bounds warning)
r? `@ghost`
`@rustbot` modify labels: rollup
Add regression test for `--cap-lints allow` and trait bounds warning
Closes#43134
I have verified that the test fails if stderr begins to contain output by making sure the test fails when I add
eprintln!("some output on stderr");
to the compiler (I added it to `fn build_session()`).
Replace a lazy `RefCell<Option<T>>` with `OnceCell<T>`
This code was using `RefCell<Option<T>>` to manually implement lazy initialization. Now that we have `OnceCell` in the standard library, we can just use that instead.
In particular, this avoids a confusing doubly-nested option, because the value being lazily computed is itself an `Option<Symbol>`.
Skip reporting item name when checking RPITIT GAT's associated type bounds hold
Doesn't really make sense to label an item that has a name that users can't really mention. Fixes#114145. Also fixes#113794.
r? `@spastorino`
privacy: no nominal visibility for assoc fns
Fixes#113860.
When `staged_api` is enabled, effective visibilities are computed earlier and this can trigger an ICE in some cases.
In particular, if a impl of a trait method has a visibility then an error will be reported for that, but when privacy invariants are being checked, the effective visibility will still be greater than the nominal visbility and that will trigger a `span_bug!`.
However, this invariant - that effective visibilites are limited to nominal visibility - doesn't make sense for associated functions.
ci: update ubuntu:20.04 builders to 22.04
This is mostly just maintenance to avoid bitrotting, but 22.04 also updates to cmake 3.22, so they don't need the manual builds from #113714 anymore.
Diagnostic namespace
This PR implements the basic infrastructure for accepting the `#[diagnostic]` attribute tool namespace as specified in https://github.com/rust-lang/rfcs/pull/3368. Note: This RFC is not merged yet, but it seems like it will be accepted soon. I open this PR early on to get feedback on the actual implementation as soon as possible. This hopefully enables getting at least the diagnostic namespace to stable rust "soon", so that crates do not need to bump their MSRV if we stabilize actual attributes in this namespace.
This PR only adds infrastructure accept attributes from this namespace, it does not add any specific attribute. Therefore the compiler will emit a lint warning for each attribute that's actually used. This namespace is added behind a feature flag, so it will be only available on a nightly compiler for now.
cc `@estebank` as they've supported me in planing, specifying and implementing this feature.
When `staged_api` is enabled, effective visibilities are computed earlier
and this can trigger an ICE in some cases.
In particular, if a impl of a trait method has a visibility then an error
will be reported for that, but when privacy invariants are being checked,
the effective visibility will still be greater than the nominal visbility
and that will trigger a `span_bug!`.
However, this invariant - that effective visibilites are limited to
nominal visibility - doesn't make sense for associated functions.
Signed-off-by: David Wood <david@davidtw.co>
new lint: [`readonly_write_lock`]
Closes#8555
A new lint that catches `RwLock::write` calls to acquire a write lock only to read from it and not actually do any writes (mutations).
changelog: new lint: [`readonly_write_lock`]
Optimize `TokenKind::clone`.
`TokenKind` would impl `Copy` if it weren't for
`TokenKind::Interpolated`. This commit makes `clone` reflect that.
r? `@ghost`
