BtreeMap range_search spruced up
#39457 created a lower level entry point for `range_search` to operate on, but it's really not hard to move it up a level of abstraction, making it somewhat shorter and reusing existing unsafe code (`new_edge` is unsafe although it is currently not tagged as such).
Benchmark added. Comparison says there's no real difference:
```
>cargo benchcmp old3.txt new3.txt --threshold 5
name old3.txt ns/iter new3.txt ns/iter diff ns/iter diff % speedup
btree::map::find_seq_100 19 21 2 10.53% x 0.90
btree::map::range_excluded_unbounded 3,117 2,838 -279 -8.95% x 1.10
btree::map::range_included_unbounded 1,768 1,871 103 5.83% x 0.94
btree::set::intersection_10k_neg_vs_10k_pos 35 37 2 5.71% x 0.95
btree::set::intersection_staggered_100_vs_10k 2,488 2,314 -174 -6.99% x 1.08
btree::set::is_subset_10k_vs_100 3 2 -1 -33.33% x 1.50
```
r? @Mark-Simulacrum
error code examples: replace some more ignore with compile_fail
Now that #68664 has been merged and `compile_fail` attempts a full build rather than `--emit=metadata`, these errors should be caught by `compile_fail` and do not need to be ignored.
Mark fn map_or() as eagerly evaluated.
In the docs for option.rs and result.rs, it is noted for all *_or()
functions that they are eagerly evaluated, except for the map_or()
function.
This commit adds this missing documentation to the two files.
Closes#68866
implement proper linkchecker hardening
r? @JohnTitor
This implements proper linkcheck filtering... we might need to fiddle with a bit to adjust what is or isn't filtered, but this seems to work reasonable locally.
Rename -Zexternal-macro-backtrace to -Zmacro-backtrace and clean up implementation.
This is my attempt at dealing with https://github.com/rust-lang/rust/pull/66364#issuecomment-565517232, although I'm not sure it's the least disruptive one.
The behavior of `-Zexternal-macro-backtrace` was already to enable full macro backtraces for *all* macros, the only part of it that was specific to cross-crate macros was showing this when *not used*:
```
note: this error originates in a macro outside of the current crate
(in Nightly builds, run with -Z external-macro-backtrace for more info)
```
After this PR:
* the flag is renamed to `-Zmacro-backtrace`
* do we need to have a deprecation period? cc @rust-lang/compiler
* the message informing you about the flag is always shown when an expansion of a bang macro/attribute/derive is involved, not just cross-crate ones
* this accounts for most of the changes in tests
* we could perhaps only show it for the bang macro case? feels odd for derives
* `fix_multispans_in_std_macros` is split into `fix_multispans_in_extern_macros` and `render_multispans_macro_backtrace`
* this roughly reverts the non-behavioral parts of #46605, which combined the two functionalities
* not sure where the old `std_macros` name came from, perhaps the `<std macros>` synthetic "file"? even then, odd that `std` specifically was mentioned
* `render_multispan_macro_backtrace`, by default (i.e. without `-Zmacro-backtrace`), hides the `in this macro invocation` label specifically to avoid redundancy in the diagnostic
* that is, showing the macro use site is only useful when the diagnostic is inside the macro definition and the user can't otherwise tell which use site it applies to, not when the diagnostic is at/inside the use site already (which would make the label redundant)
* before, it was only checking for the situation in which a cross-crate macro *definition* span would be replaced with the invocation span, which both made the connection to redundancy unobvious, and didn't help with other redundancy (e.g. when the diagnostic was pointing to an argument inside the macro invocation)
* this accounts for the remaining test changes, which I've first noticed in https://github.com/rust-lang/rust/pull/66364#discussion_r356135967 but only later understood as part of this PR (hence the "redundancy" descriptions)
This PR is not needed for #66364, but it would help, as after this PR there's only one `.span_to_filename(...).is_macros()` check (i.e. for `<... macros>` synthetic "files") left in `rustc_errors`, and it's much more self-contained.
r? @petrochenkov
In the docs for option.rs and result.rs, it is noted for all *_or()
functions that they are eagerly evaluated, except for the map_or()
function.
This commit adds this missing documentation to the two files.
stop using BytePos for computing spans in librustc_parse/parser/mod.rs
Computing spans using logic such as `self.token.span.lo() + BytePos(1)` can cause internal compiler errors like #68730 when non-ascii characters are given as input.
#68735 partially addressed this problem, but only for one case. Moreover, its usage of `next_point()` does not actually align with what `bump_with()` expects. For example, given the token `>>=`, we should pass the span consisting of the final two characters `>=`, but `next_point()` advances the span beyond the end of the `=`.
This pull request instead computes the start of the new span by doing `start_point(self.token.span).hi()`. This matches `self.token.span.lo() + BytePos(1)` in the common case where the characters are ascii, and it gracefully handles multibyte characters.
Fixes#68783.
Make associated item collection a query
Before this change, every time associated items were iterated over (which rustc does *a lot* – this can probably be further optimized), there would be N+1 queries to fetch all assoc. items. Now there's just one after they've been computed once.
Towards unified `fn` grammar
Part of https://github.com/rust-lang/rust/pull/68728.
- Syntactically, `fn` items in `extern { ... }` blocks can now have bodies (`fn foo() { ... }` as opposed to `fn foo();`). As above, we use semantic restrictions instead.
- Syntactically, `fn` items in free contexts (directly in a file or a module) can now be without bodies (`fn foo();` as opposed to `fn foo() { ... }`. As above, we use semantic restrictions instead, including for non-ident parameter patterns.
- We move towards unifying the `fn` front matter; this is fully realized in https://github.com/rust-lang/rust/pull/68728.
r? @petrochenkov
Remove `RefCell` usage from `ObligationForest`.
It's not needed.
This doesn't affect performance, it just simplifies the code a little.
r? @nikomatsakis
rustdoc: attempt full build for compile_fail test
Some code fails when doing a full build but does not fail when only emitting metadata. This commit makes sure compile_fail tests for such code behave as expected, that is, the test succeeds because the compilation fails.
Fixes#67771.
Account for HR lifetimes when suggesting introduction of named lifetime
```
error[E0106]: missing lifetime specifier
--> src/test/ui/suggestions/fn-missing-lifetime-in-item.rs:2:32
|
2 | struct S2<F: Fn(&i32, &i32) -> &i32>(F);
| ---- ---- ^ expected named lifetime parameter
|
= help: this function's return type contains a borrowed value, but the signature does not say whether it is borrowed from argument 1 or argument 2
= note: for more information on higher-ranked polymorphism, visit https://doc.rust-lang.org/nomicon/hrtb.html
help: consider making the bound lifetime-generic with a new `'a` lifetime
|
2 | struct S2<F: for<'a> Fn(&'a i32, &'a i32) -> &'a i32>(F);
| ^^^^^^^ ^^^^^^^ ^^^^^^^ ^^^
help: consider introducing a named lifetime parameter
|
2 | struct S2<'a, F: Fn(&'a i32, &'a i32) -> &'a i32>(F);=
| ^^^ ^^^^^^^ ^^^^^^^ ^^^
```
Follow up to #68267. Addresses the diagnostics part of #49287.
Move datatypes definitions in specific modules inside rustc::{traits, infer}
Prelude to #67953
Some data types inside `rustc::traits` and `rustc::infer` are used in other parts of `librustc`. These cannot go to a separate crate `librustc_infer`.
This PR moves those data types to `traits::types` and `infer::types` modules, from where everything is reexported.
Note for review: some imports feature the `crate -> rustc` substitution. This is cruft from the splitting out of #67953. This can be reverted, but are bound to be put back by #67953.
r? @Centril
cc @Zoxc
windows-gnu: prefer system crt libraries if they are available
The origin of the issue is the fact Rust ships mingw-w64 libraries but no headers and prefers own libraries over the system ones.
This leads to situation when headers aren't compatible with libraries (mingw-w64 doesn't provide any forward compatibility and AFAIK backwards compatibility is guaranteed only within major release series).
It's easier to understand how this PR works when looking at the linker invocation before and with this PR: https://www.diffchecker.com/GEuYFmzo
It adds system libraries path before Rust libraries so the linker will prefer them.
It has potential issue when system has files with the same names as Rust but that could be avoided by moving Rust shipped mingw-w64 libraries from `lib/rustlib/x86_64-pc-windows-gnu/lib` to say `lib/rustlib/x86_64-pc-windows-gnu/lib/mingw`. Then adding linker paths in this order: Rust libraries, system libraries, Rust shipped mingw-w64 libraries.
Fixes#47048Fixes#49078Fixes#53454Fixes#60912
