Updated E0559 to new format
Refactored a method that printed one suggested field name,
into a method that returns an `Option` of a suggestion
(Updated test cases accordingly)
r? @jonathandturner
Closes#36197
Update Error format for E0516, E0517, E0518
- E0518 Update error format #36111
- E0517 Update error format #36109
- E0516 Update error format #36108
- Part of #35233
r? @jonathandturner
rustdoc: Fix associated consts in search results
Associated consts can appear in none trait impls so need to be treated
like methods when generating the search index.
Fixes#36031
Fix issue #36036.
Fix#36036.
We were treating an associated type as unsized even when the concrete instantiation was actually sized. Fix is to normalize before checking if it is sized.
Fix incorrect LLVM Linkage enum
Followup of #33994 to actually work.
The `Linkage` enum in librustc_llvm got out of sync with the version in LLVM and it caused two variants of the `#[linkage=""]` attribute to break.
This adds the functions `LLVMRustGetLinkage` and `LLVMRustSetLinkage` which convert between the Rust Linkage enum and the LLVM one, which should stop this from breaking every time LLVM changes it.
Possible remaining concerns:
1. There could be a codegen test to make sure that the attributes are applied correctly (I don't know how to do this).
2. ~~The test does not exercise the `appending` linkage. I can't figure out how to make a global static raw pointer to an array. This might not even be possible? If not we should probably remove appending linkage as its unusable in rust.~~ Appending linkage is not 'emittable' anyway.
3. The test only runs on Linux.
Fixes#33992
r? @alexcrichton
Typecheck refactor for `!`
Ping @nikomatsakis @eddyb. This is the PR for the typeck refactor for `!`. Is this what you guys had in mind? Is there anything else that needs doing on it?
We were treating an associated type as unsized even when the concrete
instantiation was actually sized. Fix is to normalize before checking
if it is sized.
Use libraries from local-rust-root directory in configure when using …
…--enable-local-rebuild
When using --enable-local-rebuild configure options, the configure
script will test rustc version. But when running it, it will not use the
libraries in the local-rust-root directory.
So use `LD_LIBRARY_PATH` environment variable to correct it.
Under OpenBSD, we use `--enable-local-rebuild` for rebuilding rustc-1.11.0 using rustc-1.11.0. But as it is in use in -current (the developpment branch of OpenBSD), system libraries could easily have ABI/API changes. The (unofficial) bootstrap (rustc-1.11.0 used for building rustc-1.11.0) include several system libraries to permit it to run. The build system use libraries in stage0/lib directory. But the configure script doesn't.
Due to my special use of `--enable-local-rebuild`, I dunno if this PR is suitable for inclusion. But it corrects a difference between build and configure use of the binary.
r? @alexcrichton
Use libraries from local-rust-root directory in configure when using …
…--enable-local-rebuild
When using --enable-local-rebuild configure options, the configure
script will test rustc version. But when running it, it will not use the
libraries in the local-rust-root directory.
So use `LD_LIBRARY_PATH` environment variable to correct it.
Under OpenBSD, we use `--enable-local-rebuild` for rebuilding rustc-1.11.0 using rustc-1.11.0. But as it is in use in -current (the developpment branch of OpenBSD), system libraries could easily have ABI/API changes. The (unofficial) bootstrap (rustc-1.11.0 used for building rustc-1.11.0) include several system libraries to permit it to run. The build system use libraries in stage0/lib directory. But the configure script doesn't.
Due to my special use of `--enable-local-rebuild`, I dunno if this PR is suitable for inclusion. But it corrects a difference between build and configure use of the binary.
r? @alexcrichton
