Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0007310OCamltypingpublic2016-07-31 22:382017-07-19 14:30
Reporterjjb 
Assigned To 
PrioritynormalSeverityfeatureReproducibilityN/A
StatusacknowledgedResolutionopen 
PlatformOSOS Version
Product Version4.03.0 
Target VersionFixed in Version 
Summary0007310: per-type fragile match warning
DescriptionFor code bases that have some/many fragile pattern matches, it would be very useful if it were possible to enable warning 4 on a per-type basis. For example, perhaps an attribute could be added to a type definition which would cause all fragile matches on that type to be reported.

The use case for this feature is when extending an existing sum type in a code base with fragile matches. Currently when a new constructor is added, warnings for non-exhaustive matches can be reported. This is a huge help. It would help even more if the fragile matches on the extended type could be reported as well. After inspecting all of them, the annotation could be removed.

Another use case is where a code base prohibits fragile matches only on some but not all types.
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
(0016156)
gasche (developer)
2016-08-01 10:18

I think that this is an interesting feature request, and that a good interface (instead of a command-line option) would be an attribute on the type declaration, for example [@@fragile_pattern {error,warn,ignore,default}].

Besides 4 (fragile clauses), which other warnings would it make sense to enable on a per-declaration basis? I guess the ranges 44-45 (identifier shadowing), 40-42 (disambiguated constructors), 31-39 (unused declarations).
(0016157)
jjb (reporter)
2016-08-01 13:10

I agree that the additional warnings you mention would also make sense. But to me, the next most valuable warning to make per-declaration would be 9 (Missing fields in a record pattern).
(0016158)
gasche (developer)
2016-08-01 14:12

One thing that is unclear to me is what a good cascading semantics would be: which setting has precedence over which other setting?

In general the proper order is to favor the more specific setting over the less specific setting. Currently this means that command-line setting (and OCAMLRUNPARAM; and ocaml_compiler_internal_params before that) have less priority than local [@@warning] attributes. (Build-system-level settings are indistinguishable from command-line settings.)

While the priority of a command-line interface for this feature would be clear, declaration-specific attributes are delicate because they are along an orthogonal axis of specificity (one specific type vs. all types).

Should there be a way to disable a warning 9 fired by this type-specific feature from the command-line? Should the feature be able to silence a warning/error level explicitly set from the command-line?

One option would be to use a different warning number for this feature; warning 9 (general fragile pattern) could remain disabled by default, and the new warning (type-specific fragile pattern on enabled type) would be enabled by default.
(0016161)
octachron (developer)
2016-08-01 17:29

I would argue that this cascading semantic problem would be better solved by having parameterized warnings rather than duplicated warnings with slightly different semantics, e.g the warning 9 could have four levels:

- strict: apply to all type, attributes can not silence a warning
- standard(or implicit): apply to all types, attributes can silence warning
- lenient(or explicit): apply only to types marked by an attribute
- disabled: no warning.
(0016195)
jjb (reporter)
2016-08-08 23:59

I am not sure how this proposed finer granularity for warning 9 is fundamentally different from the existing [@@warning] and [@@warnerror] attributes on expressions. That is, there is a difference between attributing the declaration instead of the uses, but in terms of priority, I think it could reasonably be treated the same. Perhaps I'm overlooking something more subtle?
(0018101)
bobot (reporter)
2017-07-19 14:30

It seems that https://github.com/ocaml/ocaml/pull/1071 [^] implements this request.

- Issue History
Date Modified Username Field Change
2016-07-31 22:38 jjb New Issue
2016-08-01 10:18 gasche Note Added: 0016156
2016-08-01 13:10 jjb Note Added: 0016157
2016-08-01 14:12 gasche Note Added: 0016158
2016-08-01 17:29 octachron Note Added: 0016161
2016-08-08 23:59 jjb Note Added: 0016195
2016-09-07 17:00 shinwell Target Version => 4.05.0 +dev/beta1/beta2/beta3/rc1
2017-02-23 16:36 doligez Category OCaml general => -OCaml general
2017-02-25 16:13 xleroy Status new => acknowledged
2017-02-25 16:13 xleroy Target Version 4.05.0 +dev/beta1/beta2/beta3/rc1 =>
2017-02-27 16:22 doligez Category -OCaml general => typing
2017-07-19 14:30 bobot Note Added: 0018101


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker