| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Closes #30156.
|
|
cc #30346
Conflicts:
src/librustc_lint/lib.rs
|
|
This feature is partially stabilized, so describe each part in the appropriate place.
Conflicts:
src/doc/book/no-stdlib.md
|
|
|
|
More beta ports
|
|
Previously passed --cfg was used only when collecting doctests.
|
|
Checks for a `10.` prefix on the subfolder
Signed-off-by: Peter Atashian <retep998@gmail.com>
|
|
Fixes https://github.com/rust-lang/rust/issues/30229
Signed-off-by: Peter Atashian <retep998@gmail.com>
|
|
[beta] Add test for "malformed macro lhs" and change back span_bug to span_f…
|
|
|
|
|
|
|
|
[beta] Backport fix for issue 29857
|
|
exit.
I think that behavior is fine, so I am removing the expected warnings from these tests.
|
|
|
|
|
|
(this makes them handled like enum unit-variants.)
|
|
|
|
an error) but the bugfix causes this warning to propagate and become an
unresolved variable instead of a `TyError`, so we wind up seeing an
obscure inference error afterwards, which is somewhat unfortunate,
and suggests this bugfix can cause RFC 1214 warnings to become
errors.
|
|
|
|
|
|
Conflicts:
src/test/compile-fail/issue-3973.rs
|
|
the problem is that now "type_is_known_to_be_sized" now returns
false when called on a type with ty_err inside - this prevents
spurious errors (we may want to move the check to check::cast
anyway - see #12894).
|
|
of `TyError`
Conflicts:
src/test/compile-fail/issue-29857.rs
|
|
r? @eefriedman
It was getting out of hand with my additions to the const evaluator
|
|
- Successful merges: #30201, #30224, #30261, #30273, #30274
- Failed merges:
|
|
|
|
Changes to readability and some clarifications for beginners
|
|
see https://github.com/rust-lang/rust/pull/30202/files#r46819188
r? @pnkfelix
the only difference between the tests is that one has the const_indexing feature enabled.
|
|
Make clear that `super` may be included in the path several times.
r? @steveklabnik
|
|
r? @Manishearth
|
|
Fixes #26403
This adjusts the pointer, if needed, to the correct alignment by using the alignment information in the vtable.
Handling zero might not be necessary, as it shouldn't actually occur. I've left it as it's own commit so it can be removed fairly easily if people don't think it's worth doing. The way it's handled though means that there shouldn't be much impact on performance.
|
|
When given `rustc -C codegen-units=4 --emit=obj`, reset units back to 1.
Fix #30063
Note: while this code is careful to handle the case of mutliple emit types (e.g. `--emit=asm,obj`) by reporting all the emit types that conflict with codegen units in its warnings, an invocation with multiple emit types *and* `-o PATH` will continue to ignore the requested target path (with a warning), as it already does today, since the code that checks for that is further downstream. (Multiple emit types without `-o PATH` will "work", though it will downgrade codegen-units to 1 just like all the other cases.)
r? @alexcrichton
|
|
Instead of `ast::Ident`, bindings, paths and labels in HIR now keep a new structure called `hir::Ident` containing mtwt-renamed `name` and the original not-renamed `unhygienic_name`. `name` is supposed to be used by default, `unhygienic_name` is rarely used.
This is not ideal, but better than the status quo for two reasons:
- MTWT tables can be cleared immediately after lowering to HIR
- This is less bug-prone, because it is impossible now to forget applying `mtwt::resolve` to a name. It is still possible to use `name` instead of `unhygienic_name` by mistake, but `unhygienic_name`s are used only in few very special circumstances, so it shouldn't be a problem.
Besides name resolution `unhygienic_name` is used in some lints and debuginfo. `unhygienic_name` can be very well approximated by "reverse renaming" `token::intern(name.as_str())` or even plain string `name.as_str()`, except that it would break gensyms like `iter` in desugared `for` loops. This approximation is likely good enough for lints and debuginfo, but not for name resolution, unfortunately (see https://github.com/rust-lang/rust/issues/27639), so `unhygienic_name` has to be kept.
cc https://github.com/rust-lang/rust/issues/29782
r? @nrc
|
|
|
|
|
|
Changes to readability and some clarifications for beginners
|
|
This ordering was significantly more confusing.
|
|
This expands the code which generates unique IDs for Markdown headers within a single block to each rendered page.
fixes #25001
fixes #29449
|
|
This ordering was significantly more confusing.
|
|
r? @nrc
|
|
|
|
runtime code
|
|
|
|
to 1.
Fix #30063
Note: while this code is careful to handle the case of mutliple emit
types (e.g. `--emit=asm,obj`) by reporting all the emit types that
conflict with codegen units in its warnings, an invocation with
multiple emit types *and* `-o PATH` will continue to ignore the
requested target path (with a warning), as it already does today,
since the code that checks for that is further downstream.
|
|
The presence of the drop flag caused the offset calculation to be
incorrect, leading to the pointer being incorrect. This has been fixed
by calculating the offset based on the field index (and not assuming
that the field is always the last one).
However, I've also stopped the drop flag from being added to the end of
unsized structs to begin with. Since it's not actually accessed for
unsized structs, and isn't actually where we would say it is, this made
more sense.
|
|
|
|
I've measured the time/memory consumption before and after - the difference is lost in statistical noise, so it's mostly a code simplification.
Sizes of `enum`s are not affected.
r? @nrc
I wonder if AST/HIR visitors could run faster if `P`s are systematically removed (except for cases where they control `enum` sizes). Theoretically they should.
Remaining unnecessary `P`s can't be easily removed because many folders accept `P<X>`s as arguments, but these folders can be converted to accept `X`s instead without loss of efficiency.
When I have a mood for some mindless refactoring again, I'll probably try to convert the folders, remove remaining `P`s and measure again.
|
|
|
