Detect inherent method behind deref being shadowed by trait method
```
error[E0277]: the trait bound `Rc<RefCell<S>>: Borrow<S>` is not satisfied
--> $DIR/shadowed-intrinsic-method-deref.rs:16:22
|
LL | let sb : &S = &s.borrow();
| ^^^^^^ the trait `Borrow<S>` is not implemented for `Rc<RefCell<S>>`
|
help: the trait `Borrow<S>` is not implemented for `Rc<RefCell<S>>`
but trait `Borrow<RefCell<S>>` is implemented for it
--> $SRC_DIR/alloc/src/rc.rs:LL:COL
= help: for that trait implementation, expected `RefCell<S>`, found `S`
= note: there's an inherent method on `RefCell<S>` of the same name, which can be auto-dereferenced from `&RefCell<T>`
help: to access the inherent method on `RefCell<S>`, use the fully-qualified path
|
LL - let sb : &S = &s.borrow();
LL + let sb : &S = &RefCell::borrow(&s);
|
```
In the example above, method `borrow` is available both on `<RefCell<S> as Borrow<S>>` *and* on `RefCell<S>`. Adding the import `use std::borrow::Borrow;` causes `s.borrow()` to find the former instead of the latter. We now point out that the other exists, and provide a suggestion on how to call it.
Fixrust-lang/rust#41906. CC rust-lang/rust#153662.
```
error[E0277]: the trait bound `Rc<RefCell<S>>: Borrow<S>` is not satisfied
--> $DIR/shadowed-intrinsic-method-deref.rs:16:22
|
LL | let sb : &S = &s.borrow();
| ^^^^^^ the trait `Borrow<S>` is not implemented for `Rc<RefCell<S>>`
|
help: the trait `Borrow<S>` is not implemented for `Rc<RefCell<S>>`
but trait `Borrow<RefCell<S>>` is implemented for it
--> $SRC_DIR/alloc/src/rc.rs:LL:COL
= help: for that trait implementation, expected `RefCell<S>`, found `S`
= note: there's an inherent method on `RefCell<S>` of the same name, which can be auto-dereferenced from `&RefCell<T>`
help: to access the inherent method on `RefCell<S>`, use the fully-qualified path
|
LL - let sb : &S = &s.borrow();
LL + let sb : &S = &RefCell::borrow(&s);
|
```
In the example above, method `borrow` is available both on `<RefCell<S> as Borrow<S>>` *and* on `RefCell<S>`. Adding the import `use std::borrow::Borrow;` causes `s.borrow()` to find the former instead of the latter. We now point out that the other exists, and provide a suggestion on how to call it.
It's defined in `rustc_span::source_map` which doesn't make any sense
because it has nothing to do with source maps. This commit moves it to
the crate root, a more sensible spot for something this basic.
This is already CodegenResults without CrateInfo. The driver can
calculate the CrateInfo and pass it by-ref to the backend. Using
CompiledModules makes it a bit easier to move some other things out of
the backend as will be necessary for moving LTO to the link phase.
refactor(mgca): Change `DefKind::Const` and `DefKind::AssocConst` to have a `is_type_const` flag
Addresses rust-lang/rust#152940
- Changed `DefKind::Const` and `DefKind::AssocConst` to have a `is_type_const` flag.
- changed `is_type_const` query to check for this flag
- removed `is_rhs_type_const` query
r? @BoxyUwU
* refactor: add `is_type_const` flag to `DefKind::Const` and `AssocConst`
* refactor(cleanup) remove the `rhs_is_type_const` query
* style: fix formatting
* refactor: refactor stuff in librustdoc for new Const and AssocConst
* refactor: refactor clippy for the changes
* chore: formatting
* fix: fix test
* fix: fix suggestions
* Update context.rs
Co-authored-by: Boxy <rust@boxyuwu.dev>
* changed AssocKind::Const to store data about being a type const
Rename `rustc::pass_by_value` lint as `rustc::disallowed_pass_by_ref`.
The name `pass_by_value` is completely wrong. The lint actually checks for the use of pass by reference for types marked with `rustc_pass_by_value`.
The hardest part of this was choosing the new name. The `disallowed_` part of the name closely matches the following clippy lints:
- `disallowed_macros`
- `disallowed_methods`
- `disallowed_names`
- `disallowed_script_idents`
- `disallowed_types`
The `pass_by_value` part of the name aligns with the following clippy lints:
- `needless_pass_by_value`
- `needless_pass_by_ref_mut`
- `trivially_copy_pass_by_ref`
- `large_types_passed_by_value` (less so)
r? @Urgau
The name `pass_by_value` is completely wrong. The lint actually checks
for the use of pass by reference for types marked with
`rustc_pass_by_value`.
The hardest part of this was choosing the new name. The `disallowed_`
part of the name closely matches the following clippy lints:
- `disallowed_macros`
- `disallowed_methods`
- `disallowed_names`
- `disallowed_script_idents`
- `disallowed_types`
The `pass_by_value` part of the name aligns with the following clippy
lints:
- `needless_pass_by_value`
- `needless_pass_by_ref_mut`
- `trivially_copy_pass_by_ref`
- `large_types_passed_by_value` (less so)
For the attribute `FooBar` the parser is generally called `FooBarParser`
and the kind is called `AttributeKind::FooBar`. This commit renames some
cases that don't match that pattern. The most common cases:
- Adding `Rustc` to the front of the parser name for a `rustc_*`
attribute.
- Adding `Parser` to the end of a parser name.
- Slight word variations, e.g. `Deprecation` instead of `Deprecated`,
`Pointer` instead of `Ptr`, `Stability` instead of `Stable`.
tests: rustc_public: Check const allocation for all variables (1 of 11 was missing)
In the test `tests/ui-fulldeps/rustc_public/check_allocation.rs` there is a check for constant allocations of local variables of this function:
fn other_consts() {{
let _max_u128 = u128::MAX;
let _min_i128 = i128::MIN;
let _max_i8 = i8::MAX;
let _char = 'x';
let _false = false;
let _true = true;
let _ptr = &BAR;
let _null_ptr: *const u8 = NULL;
let _tuple = TUPLE;
let _char_id = const {{ type_id::<char>() }};
let _bool_id = const {{ type_id::<bool>() }};
}}
The current test only finds 10 out of 11 allocations. The constant allocation for
let _ptr = &BAR;
is not checked, because the `SingleUseConsts` MIR pass does not optimize away that assignment. Add code to also collect constant allocation from assignment rvalues to find the constant allocation for that last variable.
Not only does this change make sense on its own, it also makes the test pass both with and without the `SingleUseConsts` pass.
Discovered while investigating ways to avoid [this tests/ui-fulldeps/rustc_public/check_allocation.rs](https://github.com/Enselic/rust/commit/d7fffabc31904434cd41304c2f419f8b4abc6e70#diff-c4a926f9e8ba22bcfb1e6f2491b79b80608ab018641f85f66d6718d7f3716a5e) hack from https://github.com/rust-lang/rust/pull/151426 which wants to stop running `SingleUseConsts` for non-optimized builds.
Remove "failed to resolve" and use the same format we use in other resolution errors "cannot find `name`".
```
error[E0433]: cannot find `nonexistent` in `existent`
--> $DIR/custom_attr_multisegment_error.rs:5:13
|
LL | #[existent::nonexistent]
| ^^^^^^^^^^^ could not find `nonexistent` in `existent`
```
In the test `tests/ui-fulldeps/rustc_public/check_allocation.rs` there
is a check for constant allocations of local variables of this function:
fn other_consts() {{
let _max_u128 = u128::MAX;
let _min_i128 = i128::MIN;
let _max_i8 = i8::MAX;
let _char = 'x';
let _false = false;
let _true = true;
let _ptr = &BAR;
let _null_ptr: *const u8 = NULL;
let _tuple = TUPLE;
let _char_id = const {{ type_id::<char>() }};
let _bool_id = const {{ type_id::<bool>() }};
}}
The current test only finds 10 out of 11 allocations. The constant
allocation for
let _ptr = &BAR;
is not checked, because the `SingleUseConsts` MIR pass does not optimize
away that assignment. Add code to also collect constant allocation from
assignment rvalues. Not only does this change make sense on its own, it
also makes the test pass both with and without the `SingleUseConsts`
pass.
Return `ExitCode` from `rustc_driver::main` instead of calling `process::exit`
This makes rustc simply return an exit code from main rather than calling `std::process::exit` with an exit code. This means that drops run normally and the process exits cleanly. This is similar to what happens when an ICE occurs (due to being a panic that's caught by std's `lang_start`).
Also instead of hard coding success and failure codes this uses `ExitCode::SUCCESS` and `ExitCode::FAILURE`, which in turn effectively uses `libc::EXIT_SUCCESS` and `libc::EXIT_FAILURE` (via std). These are `0` and `1` respectively for all currently supported host platforms so it doesn't actually change the exit code.
cijiugechu