Currently, for `use` declarations with multiple paths, only the `use` item itself is saved in the AST map, not the individual path nodes. This can lead to a problem when a span of a specific path node is needed.
For example, #24818 caused an ICE because of this, in `ImportResolver::check_for_conflicting_import()`.
Fixes#25763.
Changes:
- adds explanations for E0185, E0186, E0202, E0326
- fixes the explanation for E0053. The previous description was too narrow; there are other error cases.
- changes the error message for E0202 to be specific for associated types, since it seems inherent associated constants are implemented.
Part of #24407
Closes#25046 (by rejecting the code that causes the ICE) and #24946. I haven't been able to deal with the array size or recursion issues yet for associated consts, though my hope was that the change I made for range match patterns might help with array sizes, too.
This PR is pretty much orthogonal to #25065.
Currently, for `use` declarations with multiple paths, only the `use`
item itself is saved in the AST map, not the individual path nodes. This
can lead to a problem when a span of a specific path node is needed.
For example, #24818 caused an ICE because of this, in
`ImportResolver::check_for_conflicting_import()`.
Fixes#25763.
- add feature gate
- add basic tests
- adjust parser to eliminate conflict between `const fn` and associated
constants
- allow `const fn` in traits/trait-impls, but forbid later in type check
- correct some merge conflicts
I think I didn't run tests properly - my second call to
select_all_obligations_or_error has made 3 tests fail. However, this is
just an error message change - integer fallback never worked with casts.
This should hopefully fix all cast-related ICEs once and for all.
I managed to make diagnostics hate me and give me spurious "decoder error"
- removing $build/tmp/extended-errors seems to fix it.
Constants with values that depend on generic parameters or `Self` cause
ICEs in `check_const`, and are not yet accepted via RFC, so we need to
throw a proper error in these cases.
This allows compiling entire crates from memory or preprocessing source files before they are tokenized.
Minor API refactoring included, which is a [breaking-change] for libsyntax users:
* `ParseSess::{next_node_id, reserve_node_ids}` moved to rustc's `Session`
* `new_parse_sess` -> `ParseSess::new`
* `new_parse_sess_special_handler` -> `ParseSess::with_span_handler`
* `mk_span_handler` -> `SpanHandler::new`
* `default_handler` -> `Handler::new`
* `mk_handler` -> `Handler::with_emitter`
* `string_to_filemap(sess source, path)` -> `sess.codemap().new_filemap(path, source)`
This also updates the error messages for both. For E0066, it removes mention
of "managed heap", which was removed in 8a91d33. For E0069, I just tweaked
the wording to make it a bit more explicit.
Also change several error messages to refer to "items" rather than
"methods", since associated items that require resolution during type
checking are not always methods.
There is no subtyping relationship between the types (or their non-freshened
variants), so they can not be merged.
Fixes#22645Fixes#24352Fixes#23825
Should fix#25235 (no test in issue).
Should fix#19976 (test is outdated).
* segfault due to not copying drop flag when coercing
* fat pointer casts
* segfault due to not checking drop flag properly
* debuginfo for DST smart pointers
* unreachable code in drop glue
There is no subtyping relationship between the types (or their non-freshened
variants), so they can not be merged.
Fixes#22645Fixes#24352Fixes#23825
Should fix#25235 (no test in issue).
Should fix#19976 (test is outdated).
There were still some mentions of `~[T]` and `~T`, mostly in comments and debugging statements. I tried to do my best to preserve meaning, but I might have gotten some wrong-- I'm happy to fix anything :)
Fixes the problem in #16974 with unhelpful error messages when accidentally using the wrong syntax for the `crate_type="lib"` attribute. The attribute syntax error now shows up instead of "main function not found".
If the user intended to set the crate_type to "lib" but accidentally used
incorrect syntax such as `#![crate_type(lib)]`, the compilation would fail with
"main function not found". This made it hard to locate the source of the
problem, since the failure would cause the warning about the incorrect
attribute not to be shown.
This change is worrisome to me, both because:
1. I thought the rules in RFC 599 imply that the `Box<Trait>` without `'static`
in the first case would expand to the second case, but their behaviors
here differ. And,
2. The explicit handling of `'static` should mean `dropck` has no application
here and thus we should have seen no change to the expected error messages.
Nonetheless, the error messages changed.
