Comment out `change-id` in `config.example.toml`
This way, we only update CONFIG_CHANGE_HISTORY for major changes, which is much simpler (and updating example.toml doesn't make much sense)
r? `@Kobzol` (as this was mainly your idea)
Document unstable linker flags in the unstable book
This PR:
- removes the unstable linker flavors from the stable documentation
- documents the unstable `-C linker-flavor` values in the unstable book (including the ones previously described as stable)
- documents the unstable `-C link-self-contained` components in the unstable book
I don't know if these have some common reviewers, but if not r? `@petrochenkov` as the most knowledgeable person in this area. Please feel free to reassign, I know that you are quite busy.
Fix ICE `ProjectionKinds Deref and Field were mismatched`
Fix#118144
Removed the check that ICEd if the sequence of projection kinds were different across captures. Instead we now sort based only on `Field` projection kinds.
This way, we only update CONFIG_CHANGE_HISTORY for major changes, which is
much simpler (and updating example.toml doesn't make much sense)
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Properly reject `default` on free const items
Fixes#117791.
Technically speaking, this is a breaking change but I doubt it will lead to any real-world regressions (maybe in some macro-trickery crates?). Doing a crater run probably isn't worth it.
Add better ICE messages for some undescriptive panics
Add some better messages at some panics
re: #118955
I took a look at some others but either was not able to figure out what they did, or it was unclear what they should say instead. For example in the query system whether each time a poisoned value is matched upon if they should all just call `FatalError.raise()`
[AIX] Fix XCOFF metadata
#118344 accidentally changed the way to get metadata from XCOFF file and broken our internal CI.
This PR reverts part of #118344 .
coverage: Skip instrumenting a function if no spans were extracted from MIR
The immediate symptoms of #118643 were fixed by #118666, but some users reported that their builds now encounter another coverage-related ICE:
```
error: internal compiler error: compiler/rustc_codegen_llvm/src/coverageinfo/mapgen.rs:98:17: A used function should have had coverage mapping data but did not: (...)
```
I was able to reproduce at least one cause of this error: if no relevant spans could be extracted from a function, but the function contains `CoverageKind::SpanMarker` statements, then codegen still thinks the function is instrumented and complains about the fact that it has no coverage spans.
This PR prevents that from happening in two ways:
- If we didn't extract any relevant spans from MIR, skip instrumenting the entire function and don't create a `FunctionCoverateInfo` for it.
- If coverage codegen sees a `CoverageKind::SpanMarker` statement, skip it early and avoid creating `func_coverage`.
---
Fixes#118850.
Update cargo
11 commits in 1aa9df1a5be205cce621f0bc0ea6062a5e22a98c..1a2666ddd14cf0a255d4ddb61c63531c259a7b39
2023-12-12 14:52:31 +0000 to 2023-12-17 17:53:53 +0000
- chore: downgrade to openssl v1.1.1 (rust-lang/cargo#13179)
- docs(home): prepare the changelog for 0.5.9 (rust-lang/cargo#13177)
- refactor: Pull name validation into `util_schemas` (rust-lang/cargo#13166)
- chore(deps): bump zerocopy from 0.7.29 to 0.7.31 (rust-lang/cargo#13174)
- Replace SHGetFolderPathW with SHGetKnownFolderPath (rust-lang/cargo#13173)
- chore(bump-check): dont check `home` against beta/stable branches (rust-lang/cargo#13167)
- fix: Fill in more empty name holes (rust-lang/cargo#13164)
- Do not allow empty name in package ID spec (rust-lang/cargo#13152)
- chore(deps): update rust crate openssl to 0.10.61 (rust-lang/cargo#13159)
- `all-static` feature should include `vendored-libgit2` (rust-lang/cargo#13134)
- doc/registry-web-api: Adjust success response code documentation (rust-lang/cargo#13160)
r? ghost
resolve: Replace visibility table in resolver outputs with query feeding
Also feed missing visibilities for import stems and trait impl items, which were previously evaluated lazily.
I suspect that in general this approach should work for queries that are 1) executed for most keys and 2) have results that are cheap to hash (do not have spans, in particular).
Visibility query matches that description.
