Implement split_off for BTreeMap and BTreeSet (RFC 509)
Fixes#19986 and refactors common with append methods.
It splits the tree with O(log n) operations and then calculates sizes by traversing the lower one.
CC @gereeter
Open code the __fastfail intrinsic for rtabort! on windows
As described https://msdn.microsoft.com/en-us/library/dn774154.aspx
This is a Windows 8+ mechanism for terminating the process quickly,
which degrades to either an access violation or bugcheck in older versions.
I'm not sure this is better the the current mechanism of terminating
with an illegal instruction, but we recently converted unix to
terminate more correctly with SIGABORT, and this *seems* more correct
for windows.
[breaking-change]
DirEntry.file_type().is_dir() will not follow symlinks, but the original
example (fs::metadata(&path).is_dir()) does. Therefore the change in
#33958 introduced a subtle difference that now it won't enter linked
folders. To preserve the same behavior, we use Path::is_dir() instead,
which does follow symlink.
Add AST validation pass and move some checks to it
The purpose of this pass is to catch constructions that fit into AST data structures, but not permitted by the language. As an example, `impl`s don't have visibilities, but for convenience and uniformity with other items they are represented with a structure `Item` which has `Visibility` field.
This pass is intended to run after expansion of macros and syntax extensions (and before lowering to HIR), so it can catch erroneous constructions that were generated by them. This pass allows to remove ad hoc semantic checks from the parser, which can be overruled by syntax extensions and occasionally macros.
The checks can be put here if they are simple, local, don't require results of any complex analysis like name resolution or type checking and maybe don't logically fall into other passes. I expect most of errors generated by this pass to be non-fatal and allowing the compilation to proceed.
I intend to move some more checks to this pass later and maybe extend it with new checks, like, for example, identifier validity. Given that syntax extensions are going to be stabilized in the measurable future, it's important that they would not be able to subvert usual language rules.
In this patch I've added two new checks - a check for labels named `'static` and a check for lifetimes and labels named `'_`. The first one gives a hard error, the second one - a future compatibility warning.
Fixes https://github.com/rust-lang/rust/issues/33059 ([breaking-change])
cc https://github.com/rust-lang/rfcs/pull/1177
r? @nrc
stable features lint warning mentions version stabilized
To accomplish this, we alter the checks in `rustc::middle::stability` to
use the `StabilityLevel` defined in `syntax::attr` (which includes the
version in which the feature was stabilized) rather than the local
`StabilityLevel` in the same module, and make the
`declared_stable_lang_features` field of
`syntax::feature_gate::Features` hold a Vec of feature-name, span
tuples (in analogy to the `declared_lib_features` field) rather than
just spans.
Fixes#33394.
r? @brson (tagging Brian because he [wrote](https://github.com/rust-lang/rust/pull/21958) the lint)
resolve: record pattern def when `resolve_pattern` returns `Err(true)`
I propose a fix for issue #33293.
In 1a374b8, (pr #33046) fixed the error reporting of a specific case, but the change that was introduced did not make sure that `record_def` was called in all cases, which lead to an ICE in [1].
This change restores the original `else` case, but keeps the changes that were committed in 1a374b8.
[1] `rustc::middle::mem_categorization::MemCategorizationContext::cat_pattern_`
Inline simple Cursor write calls
Implementing the Write trait for Cursors over slices is so light-weight that under some circumstances multiple writes can be fused into a single instruction. In general I think inlining these functions is a good idea because most of the code can be constant-folded and copy-propagated away.
Closes issue #33916.
r? @alexcrichton
core: check pointer equality when comparing byte slices
If pointer address and length are the same, it should be the same slice.
In experiments, I've seen that this doesn't happen as often in debug builds, but release builds seem to optimize to using a single pointer more often.
Reject a LHS formed of a single sequence TT during `macro_rules!` checking.
This was already rejected during expansion. Encountering malformed LHS or RHS during expansion is now considered a bug.
Follow up to #33689.
r? @pnkfelix
Note: this can break code that defines such macros but does not use them.
Attempt to diagnose #33844https://github.com/rust-lang/rust/issues/33844 is a spurious failure that causes builds to fail due to the linker command sometimes failing with error 206, which means that the command is too long. This PR makes rustc print out the linker arguments in that case so the reason for it being so long can be diagnosed and hopefully fixed.
r? @alexcrichton
To handle the general case, we include a vector of def-ids, so that we
can account for things like `(Foo, Bar)` which references both `Foo` and
`Bar`. This means it is not Copy, so re-jigger some APIs to use
borrowing more intelligently.
Currently, when projecting out of a higher-ranked where-clause, we
instantiate all higher-ranked regions with lifetime variables. This is
unnecessary since the language rules ought to guarantee (modulo #32330)
that each of those higher-ranked regions is equated with some regions
from the input types. This routine figures out what those regions are
and just uses them. Also, since #32330 is not fully fixed, it detects
when we may have unconstrained variables and indicates that in its
return value.
